Docs / Getting started
Calling your own endpoints
Two scripts for the question every author has right after Activate: did that work? They are curl one-liners on purpose — checking your own endpoint should not need the command line tool, a personal access token, or Node.
| What it does | |
|---|---|
webhook.sh | POSTs a JSON body to a /hooks endpoint. The platform answers 202 and your script runs afterwards. |
api.sh | The same against an /api endpoint, where the caller waits — it prints your script’s answer and exits non-zero when the call did not answer. See Answering a caller. |
The three placeholders
Both scripts take the same three, in this order.
| What it is | Where to get it | |
|---|---|---|
| the installation URL | where the platform answers, without a path — https://a9script.example.com | whoever installed it; it is the address you sign in at |
| the endpoint path | /hooks/<tenant>/<environment>/<path> or /api/<tenant>/<environment>/<path> | the endpoint’s own form shows it in full — copy it whole rather than assembling it |
| the body | the JSON you want your script to receive as input.event.body | you. It is optional: leave it out and the scripts send a small placeholder object |
./webhook.sh https://a9script.example.com /hooks/acme/sandbox/orders \
'{"id":"o-1042","customer":"ada@example.com"}'→ POST https://a9script.example.com/hooks/acme/sandbox/orders
← 202
accepted — the platform has the event; the run happens on its own.Then open the script in the browser: its run log is where what happened is.
If the endpoint asks for a credential
Nothing secret goes on the command line. Every argument of every process is
readable with ps, and your shell writes a history file — a key passed as an
argument is a key you have handed to everyone with an account on that machine
and left on disk afterwards.
Put it in a curl config file only you can read, and point A9_CURL_CONFIG at
it:
umask 077
printf 'header = "x-api-key: %s"\n' "$(cat)" > ~/.a9script-orders.curl # paste, then Ctrl-D
chmod 600 ~/.a9script-orders.curl
A9_CURL_CONFIG=~/.a9script-orders.curl ./webhook.sh https://a9script.example.com \
/hooks/acme/sandbox/orders '{"id":"o-1042"}'The same file works for a bearer token (header = "authorization: Bearer …")
or any other header your endpoint’s authentication expects.
What a signed sender’s request looks like
Some senders do not send a shared secret at all: they sign the request body with a secret both sides hold, and send the signature in a header.
POST /hooks/acme/sandbox/orders HTTP/1.1
content-type: application/json
x-signature: sha256=6f2c… the body, keyed by the signing secret
x-request-timestamp: 1774950000 what the signature also covers, so an
old request cannot be replayed
{"id":"o-1042","customer":"ada@example.com"}Which header, which digest and what exactly is signed differ per sender, and the endpoint’s form shows what yours verifies — including the ranges it accepts calls from.
These scripts do not compute that signature, deliberately. Doing it here would mean putting the signing secret on a command line, which is the one thing this page tells you not to do. Two better ways to check a signed endpoint:
- Let the real sender send. That is the thing you actually want to work, and most senders have a “send test event” button.
- Read the refusal. A signature the platform cannot verify is refused before anything runs, and the environment’s log says why — which is the same information a hand-rolled signature would have got you, without the secret ever leaving the platform.