Define a webhook or REST integration for a developer

Describe the business outcome and data boundary first, then let a developer confirm whether the installed site exposes a safe source-backed endpoint or event.

Access and dependencies

• The gym owner approves the data purpose and destination. A WordPress administrator with manage_options verifies installed integrations. A developer owns authentication, validation, retries, logging, and deployment.
• Current GymCore source exposes administrator-only REST operations for listing, connecting, disconnecting, and checking registered integration cards under /wp-json/gym/v1/admin/integrations.
• Those endpoints manage built-in cards; they are not a customer-facing webhook builder. GymCore Admin > Integrations contains no generic Webhook, Add endpoint, or REST API key control in current source.

Exact steps

Safe stop: Approve the plain-language data flow and synthetic staging case, but stop before deployment or any member-data payload until engineering verifies authentication, authorization, duplicate handling, and redacted logging.

1. Write the outcome in plain language: “When this GymCore event happens, send these fields to this named system for this business owner.” Include the consent basis and retention period.

2. Open GymCore Admin > Integrations and check for a card that already owns the destination.

   Expected: Use the built-in card when it exists. If no matching card appears, do not invent a webhook screen or reuse another provider’s credential.

3. Open Plugins > Installed Plugins and check for an approved companion extension. Record its name and version if it supplies the workflow.

4. Hand the developer the source event or record, required fields, destination, frequency, acceptable delay, duplicate rule, failure owner, and a staff-controlled test case.

   Owner handoff: Avoid endpoint jargon in the approval request. Say what leaves the gym, who receives it, why it is needed, and how to stop it. The developer can translate that into routes, signatures, and payloads.

5. The developer confirms authentication and authorization in source. The active integration-management routes require manage_options; they must not be exposed as public ingestion endpoints.

6. Deploy only to staging and send one synthetic payload that contains no member, payment, credential, or message content.

   Expected: The destination accepts one request, logs one result, and a repeated request follows the agreed duplicate rule.

7. Verify the final result in both owning systems: trigger one staff-controlled source event and compare the GymCore source record with the destination record and both systems’ timestamps.

   Expected: The owning source and destination agree on fields and status, and a failed request produces a redacted log with a named owner.

Defaults, effects, and reversal

There is no default generic webhook URL, secret, retry policy, payload, or customer UI in current GymCore source. Treat all of those as implementation requirements. Disabling custom code or deleting a credential can stop future delivery, but it cannot recall a payload already received by another system. Rotate secrets at both ends and ask the destination owner to delete copied test data.

If the implementation claim cannot be verified

• Documentation names a control that is absent: trust the installed source and UI; record the mismatch and verify extensions rather than creating a substitute.
• Request returns 401 or 403: have the developer check WordPress authentication, REST nonce handling, and the required capability; do not weaken the permission callback.
• Destination receives duplicates: stop the integration and add an idempotency rule before another live test.
• A secret or member payload reached logs: rotate the secret, restrict the log, and follow the gym’s incident process.

Related guides

• Credentials Webhooks
• Integrations API
• Scheduled Jobs Automation