TOS Links

Three endpoints related to the hosted Terms of Service flow. All three return a TOS acceptance URL. The differences are when you call them and what you get back.

• POST /customers/tos_links: create a fresh TOS link during onboarding.
• POST /customers/tos_acceptance_link: alias of tos_links (Bridge renamed the route; both still work).
• GET /customers/{id}/tos_acceptance_link: read back the TOS link attached to an existing customer, with accepted_at filled in once the flow completes.

POST /customers/tos_links

Hosted URL for Terms of Service acceptance during new-customer onboarding. Send an Idempotency-Key header on repeated calls so you don't spawn duplicate links.

Body: empty.

Response (200)

{
  "url": "https://tos.seismic.systems/flow/abc123"
}

curl -X POST "$BASE_URL/customers/tos_links" \
  -H "Api-Key: $SEISMIC_ORCHESTRATION_API_KEY" \
  -H "Idempotency-Key: $(uuidgen)"

POST /customers/tos_acceptance_link

Alias of POST /customers/tos_links. Same empty body, same response shape. Bridge exposes both route names for historical reasons. Use whichever your existing Bridge code hits.

curl -X POST "$BASE_URL/customers/tos_acceptance_link" \
  -H "Api-Key: $SEISMIC_ORCHESTRATION_API_KEY" \
  -H "Idempotency-Key: $(uuidgen)"

GET /customers/{id}/tos_acceptance_link

Read back the TOS acceptance link attached to an existing customer. Returns the same object POST /customers/tos_links originally produced, with acceptance state filled in.

Response (200)

{
  "url": "https://tos.seismic.systems/flow/abc123",
  "accepted_at": "2026-04-24T12:00:00Z"
}

accepted_at is null until the customer completes the hosted flow.

curl "$BASE_URL/customers/cust_01HZ…/tos_acceptance_link" \
  -H "Api-Key: $SEISMIC_ORCHESTRATION_API_KEY"