Developer guide · Automation
Automate loyalty tasks through supported HTTP boundaries.
Use a generic webhook step for notifications and a scoped API request for supported actions. Your automation owns credentials, mapping, recovery, and downstream behavior.
- Trigger direction
- Reward Loyalty to automation
- Action direction
- Automation to Agent API
- Connector status
- Verified templates, no native connector
Short answer
Separate the trigger from the command.
Reward Loyalty has no native connector for Zapier or Make, and ships verified automation templates instead: an importable Make blueprint and an importable n8n workflow, both proven end to end, plus a guided recipe for Zapier that was exercised in the editor rather than published. A generic webhook trigger can receive signed outbound webhooks after supported loyalty events. That path is notification-only: it cannot award points, approve a redemption, or replace a write API. When an automation must read or change loyalty data, its trusted HTTP step can call the Agent API with a long-lived key and least privilege. The integrator owns mapping, signature handling, duplicate defense, consent, retries, and reconciliation.
For supported operations, scopes, rates, and recovery, follow the complete machine-to-machine API walkthrough.
Decision criteria
Design automation as two controlled directions.
Outbound notifications and authenticated API actions have different trust, retry, duplicate, and customer consequences.
Trigger event
Choose the narrow business fact that should start the workflow. Broad balance events and detailed action events can describe related outcomes, so avoid triggering the same side effect twice.
Action authority
Decide whether the workflow only notifies another system or must make a supported API call. Give an action key only the role and scope needed for that task.
Failure owner
Name the operator who reviews failed deliveries, automation runs, API errors, duplicate skips, rate limits, and customer consequences across both systems.
Automation boundary
Use generic webhooks and API requests.
Zapier and Make can orchestrate HTTP. Reward Loyalty does not claim a published app or native connector for either service, and does ship verified automation templates a business imports and fills in.
Reward Loyalty supplies
The application ships verified automation templates for in-person sales, sends signed outbound webhooks, exposes delivery evidence, and accepts supported Agent API operations when the feature and caller permissions allow them.
Developer supplies
Configure the webhook catch or receiver, map fields, verify trust, store processed delivery IDs, protect the Integration API key, define API requests, and own the downstream workflow.
Operator supplies
Choose events and destinations, approve data use, grant narrow access, monitor both services, resolve failures, rotate secrets, and maintain the automation after product changes.
Branding scope
White-label relevance: Supporting. Agencies can present an operated service under their own customer relationship, while automation configuration, support, source changes, and license limits remain their responsibility.
Trigger flow
Treat the webhook as an at-least-once notification.
The event reports a committed loyalty fact. It does not ask the automation service to commit that fact again.
-
1
Subscribe narrowly
Enable the current webhook feature, add a public HTTPS destination, choose only the events the workflow needs, and send a safe test delivery.
-
2
Verify before action
Validate the signature from the raw body and endpoint secret before trusting fields. If the automation tool cannot enforce that control, place a small verified receiver in front of it.
-
3
Claim the delivery ID
Store the delivery ID before email, CRM update, ticket, or other side effect. A retry can deliver the same ID again, and event ordering is not guaranteed.
-
4
Minimize personal data
Use stable member identifiers from the event and fetch more only when the task needs it. Apply retention, deletion, consent, and subprocessor rules to the automation account.
Action flow
Use the Agent API for supported commands.
A reverse write needs its own authentication, authorization, validation, and recovery design.
Authentication
Store the long-lived Integration API key in the automation service secret field or a trusted middleware secret store. Send it through the documented X-Agent-Key header, never in a public hook URL or browser step.
Authorization
Choose a partner, member, or administrator owner that matches the task, then restrict the key to the needed scopes. Partner calls also require the current feature permission and resource ownership.
Reads and writes
Use documented reads to resolve current state and documented writes for supported actions. Do not turn an arbitrary webhook payload into a generic API command.
Ambiguous results
A purchase carrying a stable sale reference is retry-safe: the identical request returns the original transaction rather than a second award. Purchases without one, and redemption and deduction writes, are non-idempotent: after a timeout or unknown result, reconcile the ledger and external reference before retrying.
Production controls
Monitor every boundary the workflow crosses.
A green automation run can still hide a skipped webhook, denied scope, repeated side effect, or customer message sent without the right consent.
Delivery evidence
Review endpoint status, delivery ID, event, attempts, response code, error summary, and pause state in Reward Loyalty. The outbound service controls its documented retry schedule.
Automation evidence
Keep the run ID, mapped event and member identifiers, branch result, downstream response, and redacted error. Do not log webhook secrets, Integration API keys, or raw personal-data payloads.
API evidence
Record the Agent API response code, structured retry guidance, request trace, and resulting business record. Observe per-key rate headers and audit activity.
Release checks
Re-test valid, invalid-signature, duplicate, delayed, out-of-order, rate-limited, revoked-key, validation, and destination-failure cases after changing the automation.
Product and operating limits
A generic HTTP step is not a native connector.
- Reward Loyalty does not ship or promise a native Zapier app, native Make app, managed automation library, or support for every action offered by either platform.
- Outbound webhooks are notification-only and at-least-once. They do not create reverse authorization, guarantee order, or make downstream side effects idempotent.
- The automation owner is responsible for third-party terms, subprocessors, data location, consent, retention, incident response, and the cost and reliability of each external step.
Implementation guides
Use current documentation for changing details.
Requirements, interfaces, settings, limits, and release behavior belong in the maintained product documentation.