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
- Generic HTTP configuration
Short answer
Separate the trigger from the command.
Reward Loyalty has no native connector for Zapier or Make. 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.
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, but Reward Loyalty does not claim a prebuilt app, managed recipe, or native connector for either service.
Reward Loyalty supplies
The application can send signed outbound webhooks, expose delivery evidence, and accept 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 Agent 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 Agent 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
Purchase, redemption, and deduction writes are non-idempotent. After a timeout or unknown result, reconcile the ledger and external reference before a human or automation retries the command.
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, Agent 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.