Envara ConnectDocs

API keys

API keys are issued per site from the dashboard. There is no global account-level key — each site you create gets its own pair of credentials, so revoking one site never affects another.

Get a key

  1. Sign in to the dashboard: https://bridge.envara.ae/login
  2. Go to Sites → Add site.
  3. Pick a name, paste the platform URL, and choose the source type (woocommerce, shopify, or genericfor any custom backend).
  4. On success the dashboard shows two values once:
    • API key — sent as the X-Envara-Site-Key header.
    • Webhook secret — used to sign request bodies with HMAC-SHA256.

Create API key in dashboard →Or read the quickstart

Store them safely

Copy both values immediately into your secret manager. The dashboard cannot show them again — you'd have to rotate the secret or recreate the site.

.env
ENVARA_SITE_KEY="ec_live_xxxxxxxx..."ENVARA_WEBHOOK_SECRET="ecs_xxxxxxxx..."

Never expose these in a browser. Sign and send requests from your server, edge function, or backend worker only.

Use them in requests

Every request to /api/public/ingest/{source}/{event} must include the API key as a header and a fresh HMAC signature of the body.

bash
curl -X POST https://bridge.envara.ae/api/public/ingest/generic/order.created \  -H "Content-Type: application/json" \  -H "X-Envara-Site-Key: $ENVARA_SITE_KEY" \  -H "X-Envara-Signature: sha256=<hex>" \  -H "X-Envara-Timestamp: $(date +%s)" \  -d "$BODY"

Full signing recipes for Node, PHP, Python, Go and Ruby live in Recipes. Test your signature in the browser with the HMAC tester.

Lost the key or secret?

  • Lost API key — delete and recreate the site to issue a fresh key. (Bindings stay associated with the site's UUID, not the key, so they survive recreation only if you re-bind them. For zero downtime, create a new site first and migrate.)
  • Lost or leaked webhook secret — rotate it from the Site detail page. The old secret is invalidated immediately, so deploy the new one to every server that signs requests first.

One key per environment

We recommend creating separate sites for staging and production. That way your staging environment can fire freely without polluting production delivery logs, and you can hand a staging key to a developer without exposing the production secret.

What's next