Update next IDs for site

PUT /api/configuration/system/sites/{id}/next-ids

• Products: Operator (FOH)
• Features: Front of House Generic Access (FOHGENERIC)

Overview

Sets the identifier counters for one site. These counters are how the platform allocates the next member number, booking id, sale invoice id and so on: when a record is created, the counter is incremented and the record gets the value it held beforehand. The numbers live in configuration, which is why they are editable at all, and why editing them is dangerous.

Treat this endpoint as a repair tool, not part of a normal integration.

Setting a counter backwards re-issues numbers that are already in use. The next record created will be given an identifier that an existing record already has, so you should expect failed record creation — members, invoices and so on — and, for references that are not required to be unique, two records sharing one number. There is no validation against the highest identifier already issued; the value you send is saved as-is. Only ever move a counter forwards unless you have verified that nothing occupies the range you are moving into. Gaps are harmless: a reserved identifier that is not used is simply skipped.

This is a full replacement of all 23 counters, not a partial update. Every field is written on every call from the value in the body, and there is no "leave this one alone". All 23 are required integers, so an omitted field cannot be distinguished from a deliberate 0 — and 0 would reset that counter. Read the current values with GET /api/configuration/system/sites/{id}/next-ids, change only what you mean to change, and send all 23 back.

Site-specific identifiers must be switched on. If the system configuration Database_EnableSiteSpecificIDs is not 1, the request is rejected with 400 Site specific ids is not enabled — and note that when it is 0 identifiers are allocated from the counters held against site HO whatever the site, so per-site counters would have no effect anyway.

The site must already have counter records; a site with none returns 404. The 23 writes are saved together, so the call is all-or-nothing.

On success the response is 204 No Content.

Endpoint

PUT {base_url}/api/configuration/system/sites/{id}/next-ids

{base_url} is the environment URL issued to your integration. See Authenticating with Gladstone APIs.

Path parameters

Request body

Sample request

curl -X PUT '{base_url}/api/configuration/system/sites/{id}/next-ids' \
  -H 'Authorization: Bearer {accessToken}' \
  -H 'X-Use-SSO: true' \
  -H 'Content-Type: application/json' \
  -d '{
  "nextAccompaniedAttendance": 1,
  "nextBookingID": 12345,
  "nextBookingRef": 1,
  "nextCancellationRef": 1,
  "nextCorrespondenceID": 12345,
  "nextDirectDebitDate": 1,
  "nextEFTRunID": 12345,
  "nextEFTTransactionID": 12345,
  "nextEventLogID": 12345,
  "nextInvoiceID": 12345,
  "nextMailID": 12345,
  "nextMemberActionID": 12345,
  "nextMemberID": 12345,
  "nextOnlineAuthID": 12345,
  "nextProductReferenceId": 12345,
  "nextSalesInvoiceID": 12345,
  "nextSalesReceiptID": 12345,
  "nextSubscriptionRef": 1,
  "nextTerminalReadingId": 12345,
  "nextUserReadingId": 12345,
  "nextWaitinglistRef": 1,
  "nextXReadingId": 12345,
  "nextZReadingId": 12345
}'

Errors

This page as markdown · All pages · llms.txt