Legal
Terms and policies
What you agree to when you call the API, and what Halyard commits to in return.
Updated 13 August 2026In force since 1 June 202530 days notice
The agreement
Creating a key is the acceptance. There is no separate signature, and the version in force is the one on this page on the day the call is made.
Your messages stay yours. Halyard stores them to deliver them, reads them only to deliver them, and never trains anything on them. You can delete a queue and its contents at any time, and the deletion is immediate rather than scheduled.
A term on this page changes with 30 days notice, sent to the account address. An API shape is a different promise and keeps its own schedule: a removed shape gets the 90 day overlap the v2.0.0 release note records, and every breaking change appears in the changelog before it ships.
Either side can end the account with 30 days notice. Halyard can end it immediately for the uses below, in which case queued messages stay readable for 14 days so you can drain them.
Acceptable use
A queue is a delivery mechanism, not storage. Publishing messages you never intend to lease, to hold data cheaply, is the one use of the API that is out of bounds by design rather than by volume.
The rest is what you would expect. Do not put someone else’s data through a queue without the right to, do not use Halyard to send unsolicited mail, and do not attempt to read a queue that is not yours. Scopes make the last one hard; the scope table says what each one opens.
Load testing is welcome and needs no permission below the published ceilings. Above them, ask support for a raise first: an unannounced burst reads as an incident and gets handled as one.
Careful
What is stored
Five things, and nothing else. A queue’s region is fixed when it is created, and everything in the table below stays in that region for its whole life.
| Message bodiesuntil acked | Held in the queue's own region across three availability zones, and deleted when the lease that carries them is acknowledged. |
|---|---|
| Dead letters14 days | A message that exhausts max_deliveries keeps its full delivery history for 14 days, then it is deleted whether or not it was replayed. |
| Request logs30 days | Method, path, status, timestamp and idempotency key. No bodies. This is what support reads when you send a timestamp. |
| Idempotency keys24 hours | The key and the id it returned, so a retry inside the window answers with the original message instead of a second copy. |
| API keysuntil revoked | Stored hashed. A key is shown once, at creation, and cannot be read back afterwards by you or by Halyard. |
The four regions are eu-west, us-east, us-west and ap-south. Choosing one is how residency is handled: there is no global replication to opt out of, because there is none to begin with.
Availability
The delivery path carries a 99.9% monthly target per region. Everything the target covers, and everything it pays, is in the table.
| Publish and lease99.9% monthly | Measured per region on requests that reach Halyard. A 503 during a failover counts against it; a 429 against your own ceiling does not. |
|---|---|
| Management calls99.5% monthly | Queue creation and deletion. They are rarer, they are slower, and they are not on the delivery path. |
| Credit10% of the month | One credit per region per month, applied to the next invoice. It is the whole remedy for a missed target. |
| Claim window30 days | Send the region, the window and a request id. Support opens the claim from the same report the incident used. |
A single 503 region_unavailable is a failover rather than an outage, and it is measured but not usually claimable on its own. When it is an incident says what to watch and when to write.