Skip to navigation
APIBuild an integration

Test your sender

Run these checks with a test key and a copy of your outbox. Test sends do not reach your church’s data. Keep test delivery state out of the live outbox. The checks use assessment records because that is the only supported type today.

Read endpoints

Use the same test key for these reads; both require records:status scope.

  • GET /v1/records/{record_type}/{record_id}: Returns the current revision’s receipt with type, ID, revision, definition, hash, counts, receipt time and state. It does not include answers, subjects or a link decision. Use formation.assessment_result for {record_type} in this test.
  • The same GET after deletion: Returns HTTP 410 with state: "deleted" and hash: null. Unknown IDs return 404.
  • GET /v1/records?since=2026-10-01T00%3A00%3A00Z: Returns one entry per record at its current revision, including deleted records, plus next_cursor. since is inclusive; limit can be 1–500.

For reconciliation, send next_cursor unchanged as cursor with the same since until it becomes null. Do not advance since from a row’s received_at: a later deletion keeps the prior revision’s receipt time. See the API reference for the response schemas.

Acceptance checks

1

Send a valid definition and record

Expect HTTP 202 with outcome: "accepted". Save the receipt.

2

Send the exact same record again

Expect HTTP 200 with outcome: "duplicate".

3

Change its body without changing revision

Expect HTTP 409 with rule: "revision_conflict".

4

Send revision 2 with a changed value

The status GET should report revision 2 as current.

5

Send an invalid record

Expect a problem with rule, JSON pointer and fix; correct it before resending.

6

Delete a record, then send a later revision

The status GET should return HTTP 410 with a deletion receipt; the later revision should be refused.

7

Reconcile

Each record should appear once at its current revision.

8

Simulate an outage and retry

Send with Ediphai-Simulate: unavailable; retry after the 503. The record should be neither lost nor duplicated.

After these checks, inspect what your app logged. Keys, private answers and full request bodies do not belong in shared logs or tickets. A test receipt proves request handling only; it does not prove a live record landed, linked to the right person or became queryable.