Skip to main content
All API calls are authenticated with a bearer token and target https://triggers.litprotocol.com. Every trigger needs a scoped Chipotle usage API key permitted to execute the action — mint one in the Dashboard or via the management API.
If you are an AI agent setting this up on a user’s behalf, a machine-readable guide lives at https://triggers.litprotocol.com/SKILL.md. It covers the browser-based authorization handshake step by step.

Authorize

Access is granted through pairing with a logged-in browser session. Generate (or reuse) a local bearer token, then send its SHA-256 hash to POST /agent/pair. The server returns a single-use authorization URL and a confirmation code. Run this command and leave it running while you approve in the browser:
Open the printed URL, sign in via email if needed, and compare the code on the page with the printed confirmation code before clicking Authorize agent. The pairing expires after 10 minutes. The command polls POST /agent/pair/complete until approval is complete, proving possession of the token with a bearer header. The raw token is never included in the browser URL; it is sent to the service in the authorization header for completion and subsequent API calls. After the command reports Agent authorized., load the saved token into your shell and verify API access. Use this same $TOKEN for the examples below:
If pairing fails or expires, rerun the pairing command to get a fresh URL while keeping the saved token. A 401 from /api/me also means you need to pair again.

Create a webhook trigger

An external service POSTs JSON (or text) to a generated URL; each POST fires a run.
Fire it at POST /webhook/<trigger-id> (public; returns 202 with a run id):
The action receives the parsed body as params.event, the exact raw bytes as params.event_raw, and safe headers as params.headers. Verification headers (x-hub-signature-256, x-github-event, stripe-signature, x-slack-signature, …) are passed through so you can verify the sender; secret-bearing headers (authorization, cookie, x-api-key) are stripped.

Create a schedule trigger

config.cron is a 5-field cron (or 6-field with seconds). Sub-30-second schedules are rejected — the scheduler scans every 30 seconds.
Schedule runs pass params flat: { source: "schedule", scheduled_at, cron }.

Create a chain-event trigger

Fires when a log matching the contract + event signature appears on a supported chain: ethereum, base, arbitrum, bsc, polygon. The deployment must have the chain’s RPC configured.
Optional config:
  • start_block — integer or hex string to backfill from.
  • topic_filters — up to three entries after topic0; each is a 32-byte topic, an array of topics, or null (wildcard).
Chain-event runs include ABI-decoded args (event.decoded.arg0, arg1, …) alongside the raw log, transaction hash, block number, and topics.

Inspect and manage

A run progresses queued → running → success | failed. Transient (5xx) failures from the Lit network are retried up to 3 times with backoff; the run’s response/error captures the action’s output or the failure (including a JS stack trace when the action throws).

API reference