Load the country list first
Call `holidays-countries` when your settings page loads and keep the returned `countryCode` values in your own storage. Use those codes to validate `body.country` in your forms, so users cannot pick a country that is not supported.
Checking a due date
Before confirming a delivery or payment date, send it to `holidays-is-workday` as `body.date`. If the answer is not a working day, the response includes `reasons` that you can show to the user before suggesting the next date.
Counting lead time across regions
For lead-time estimates call `holidays-workday-count` with `body.start` and `body.end`. Add `body.subdivision` when regional holidays matter, for example a state-level holiday, and keep the same subdivision for every request that belongs to one plan.
Pitfalls specific to this data
Send exactly one holiday type in `body.types`, spelled as listed (for example `Bank`); a comma-separated list or another spelling is not accepted by the contract. If you leave it out, only `Public` counts as a day off, so a day outside the weekend that is only a bank or school holiday does not count as a day off. Use the documented field names rather than aliases, keep years from 1900 to 2200, and send dates as YYYY-MM-DD strings, because the contract does not check the date format itself. Keep each `holidays-workday-count` range within about 10 years. Invalid `body.subdivision`, `body.weekend` and `body.today` values are not refused: they are ignored and the defaults apply (nationwide rules, the default weekend and the current UTC date), so a mistyped subdivision produces a nationwide answer rather than an error. Check these values in your own code before sending them, for example against your list of ISO-3166-2 codes and day names such as `Sat,Sun`.
[
{
"body": {
"country": "GB",
"date": "2027-12-27",
"subdivision": "GB-SCT"
}
},
{
"body": {
"country": "GB",
"start": "2027-12-01",
"end": "2027-12-31",
"subdivision": "GB-SCT"
}
}
]Server-side request template
This server-side template shows authentication and request identity using the first operation of this API. Choose the operation for your use case and check its current availability and price on the API page. After a timeout, resend the unchanged request with the same Idempotency-Key.
The gateway request is always POST.
Use a JSON object with the documented path, query, headers and body locations; omit unused locations. input.headers is schema-validated data, not browser request headers. Do not put credentials here. Keep body arrays, scalar values and null as documented; omission is different from null.
# Server-side only. Set ATLAS_API_KEY in your secret manager.
# Set ATLAS_API_ORIGIN to your configured deployment origin.
# Every gateway operation is called with POST.
# Only operations shown as enabled on the API page can be called.
# Generate once per intent; retain the same value on status checks.
REQUEST_ID="$(uuidgen)"
curl --request POST 'https://apigate.vercel.app/api/v1/holidays/holidays-countries' \
--header "Content-Type: application/json" \
--header "x-api-key: $ATLAS_API_KEY" \
--header "Idempotency-Key: $REQUEST_ID" \
--data '{"body":{}}'Integration checklist
- The API key is stored in a server-side secret manager and never sent to a browser.
- Each request carries its own Idempotency-Key, kept until the request has a final answer.
- The integration reads ok and error.code and handles each error code as the error table describes.
- An uncertain POST is inspected using its original identity, never blindly repeated with a new one.
- The operation’s current availability and price have been checked on its API page.