AffiliateWP REST API Extended v1.2.1

AffiliateWP REST API Extended v1.2.1 Overview

AffiliateWP REST API Extended v1.2.1 expands AffiliateWP’s read-only REST interface with Create, Update, and Delete operations. It gives authenticated external systems a programmatic way to manage affiliates, creatives, referrals, visits, and payout records without relying on the WordPress administration screens for every change.

The add-on is intended for developers building integrations between AffiliateWP and external websites, commerce platforms, customer databases, reporting tools, internal applications, or custom affiliate dashboards. It can synchronize affiliate accounts across systems, create referrals after an external payment is confirmed, update records from another application, and remove data through controlled workflows.

This capability is powerful because it exposes financial and identity-related data to remote write operations. Installation alone is not a complete integration. A production implementation needs authenticated requests, HTTPS, least-privilege user capabilities, input validation, idempotency, audit logs, backups, error handling, and a clear data-ownership model.

How The Add-On Extends AffiliateWP Core

AffiliateWP core provides read access to its REST API so an authenticated consumer can retrieve records. REST API Extended adds the missing write operations, creating a full CRUD workflow: Create, Read, Update, and Delete. The external application can therefore do more than display information; it can change the AffiliateWP database through supported endpoints.

The add-on covers five main resource types: affiliates, creatives, referrals, visits, and payouts. Each resource has its own fields and business rules. Creating a visit is not equivalent to creating a referral, and creating a payout record is not automatically the same as transferring money through a payment provider.

Endpoint groups can be enabled from the AffiliateWP REST API settings. Activate only the operations the integration genuinely needs. A reporting dashboard may need read access but no delete capability. An order processor may need to create referrals but should not be able to remove affiliates or payout history.

Supported REST Resources

• Affiliates: Create affiliate accounts, retrieve one or many affiliates, update supported affiliate fields, and delete an affiliate through an authorized workflow.
• Creatives: Manage banners, text links, and other promotional assets that affiliates can use.
• Referrals: Create commission records from supported external events, review existing referrals, update fields or statuses, and delete records when an approved process requires it.
• Visits: Record or manage affiliate visit data used in tracking and reporting.
• Payouts: Create, retrieve, and delete payout records where supported. Payout records must be reconciled with actual money movement.

The API also supports discovery through OPTIONS requests. A developer can inspect available methods, schemas, and accepted arguments rather than guessing field names. Check the response of the installed version because schemas can change across AffiliateWP releases.

REST Route Patterns And HTTP Methods

AffiliateWP exposes its namespace beneath /wp-json/affwp/v1/. Collection routes follow patterns such as /affiliates, while an individual item uses a numeric identifier such as /affiliates/123. Other resource names follow the same general model.

A GET request retrieves records. Depending on the documented route, POST or PUT can create a new item, PATCH updates an existing item, and DELETE removes an item. The official documentation notes that collection and item routes can accept OPTIONS for endpoint discovery.

Do not assume that every HTTP verb works on every URL or that POST and PUT are interchangeable in all versions. Generate test requests from the schema exposed by the installed site, verify required parameters, and compare the returned object with the desired state.

AffiliateWP API Key Authentication

API keys are generated from AffiliateWP’s Tools and API Keys area for a specific WordPress user. Authentication uses a Public Key and Token through Basic Authentication, with the public value supplied as the username and the token as the password. The Authorization header must accompany each protected request.

The associated WordPress user’s capabilities determine what the API consumer is allowed to do. Documentation examples often use an administrator because it has the necessary access, but giving a permanent integration full administrator capability increases risk. Where the application and AffiliateWP version allow it, use a dedicated service user with the minimum required capabilities.

Basic Authentication must be used over HTTPS. Without transport encryption, headers can be exposed in transit. Never place the token in a public URL, browser-side JavaScript, mobile application bundle, support screenshot, analytics event, or source repository.

Managing API Keys Safely

Create separate key pairs for production, staging, and each external system. A shared credential makes it difficult to identify which integration performed an action and forces every consumer to change when one key is compromised.

Store secrets in a server-side secret manager or protected environment configuration. Restrict access to the deployment process and authorized operators. Do not hard-code a token in a public plugin, theme, frontend script, or downloadable example.

Rotate keys on a schedule and immediately after suspected exposure. Revoke unused keys when an application is retired or a staff member leaves. Record key ownership, purpose, created date, last verified use, and planned rotation date without recording the secret itself in a general inventory.

Creating Affiliates Programmatically

An external CRM, partner portal, or registration application can create an AffiliateWP affiliate after the required review. The request must supply the fields expected by the affiliate endpoint and must map the external identity to the correct WordPress user or supported account structure.

Prevent duplicate affiliates by using a stable external identifier and checking for an existing mapping before creation. Email alone may be insufficient because addresses change, case handling differs, and several systems can normalize data differently. Store the AffiliateWP affiliate ID returned by the successful response.

Creating an affiliate should not silently bypass program approval, tax onboarding, consent, or fraud checks. The API performs a technical action; the integration must enforce the business workflow that would normally surround the admin screen.

Updating Affiliate Records

Updates can synchronize status, rate, identity mappings, or other supported values from an external source. Decide which system is authoritative for each field. If WordPress and the CRM both edit the same value, a two-way synchronization loop can overwrite a newer change with stale data.

Use PATCH for targeted changes when supported and send only intended fields. A full-object update built from an old cached record may erase values added by another process. Compare update timestamps or use version markers when the external architecture supports optimistic concurrency.

Log the affiliate ID, external correlation ID, fields changed, requester, result, and timestamp. Avoid logging sensitive personal values or authentication headers.

Deleting Affiliates Through The API

A DELETE operation can remove important program data. AffiliateWP’s documented response can include deleted: true and a copy of the deleted object, allowing the client to confirm which record was affected. That response does not make deletion automatically recoverable.

Prefer deactivation or an approved retention workflow when financial history must remain auditable. An affiliate may be linked to referrals, payouts, visits, tax records, and legal agreements. Deleting the main record without understanding those relationships can leave incomplete reporting.

Require elevated authorization for delete endpoints, make the user confirm the exact ID, and test on staging. For bulk deletion, use a dry-run report and a recoverable backup instead of sending unreviewed requests from a spreadsheet.

Creating Referrals From External Commerce Systems

One major use case is referral tracking for a non-WordPress store or a custom payment processor. The external system determines that an order belongs to an affiliate, then calls the AffiliateWP referrals endpoint with the supported amount, affiliate ID, reference, description, context, status, and other required fields.

The integration needs a trustworthy attribution rule. Never accept an affiliate ID supplied by the shopper without validation. Verify the affiliate is active, the order is eligible, the amount is commissionable, and the event came from an authenticated commerce service.

Use the external order or transaction ID as a stable reference and enforce idempotency. Payment providers can retry events, and network timeouts can make the caller uncertain whether the first request succeeded. Before creating another referral, search for the reference or store the successful AffiliateWP referral ID.

Updating Referral Status And Amount

An external application may need to change a referral from pending to unpaid after an order clears, reject it after a refund, or correct an approved calculation. Build a strict state machine rather than accepting arbitrary status changes from any request.

Once a referral is paid, changing or deleting it can cause AffiliateWP to disagree with accounting and the payout provider. Treat paid records as controlled financial history. Corrections may require an adjustment record rather than rewriting the original event.

Validate currency and rounding consistently. AffiliateWP referral values and the external order system must agree on decimal precision, tax, shipping, discounts, and exchange rates. Include the calculation basis in internal logs.

Managing Creatives Through External Tools

A design asset manager or marketing platform can create and update AffiliateWP creatives through the API. This can keep campaign names, destinations, image URLs, and promotional text synchronized without manual copying.

Validate every destination and media URL. An attacker who gains creative-write access could insert a phishing link or untrusted asset into the affiliate dashboard. Restrict allowed domains, sanitize descriptive content, and require approval before a remotely created creative becomes active.

When deleting a creative, remember that affiliates may have copied its URL into live campaigns. Retiring or replacing the asset with a stable redirect can be less disruptive than immediate deletion.

Creating And Managing Visits

External visit tracking can record affiliate traffic from a non-WordPress property or custom application. A visit should contain enough validated context to support reporting and a later referral relationship without storing unnecessary personal data.

Visit endpoints are particularly vulnerable to high volume and abuse. Apply rate limits, origin validation, bot controls, queueing, and duplicate detection. Do not expose a privileged AffiliateWP API token in the browser to send each page view directly; route requests through a controlled server-side service.

Privacy and retention policies must cover IP addresses, URLs, campaign values, cookies, and other identifiers the integration records. Minimize data and avoid placing secrets or personal values in query strings.

Working With Payout Records

The payouts resource lets an authorized application manage AffiliateWP payout records. A payout record is an accounting object inside AffiliateWP. Creating it does not necessarily send funds through PayPal, Stripe, a bank, or another provider unless a separate supported payout process explicitly performs that transfer.

Separate the money-movement service from the record-keeping call. The integration should submit payment, receive a definitive provider result, and then update AffiliateWP according to an idempotent reconciliation workflow. If the provider times out, check its transaction history before retrying.

For legacy PayPal payment workflows, review AffiliateWP PayPal Payouts Addon v1.4.1. Do not create an API payout record merely to make unpaid referrals disappear; reconcile the real transfer, provider ID, recipient, amount, and currency.

Cross-Site Affiliate Synchronization

REST API Extended can synchronize affiliates between multiple WordPress installations or between WordPress and another database. The design needs a stable mapping table. Affiliate ID 25 on Site A may represent a different person from Affiliate ID 25 on Site B.

Choose a primary system for account creation and define how changes flow. One-way synchronization is simpler. Two-way synchronization requires conflict rules, timestamps, loop prevention, and a way to merge records safely.

Do not copy password hashes or authentication cookies through AffiliateWP endpoints. Synchronizing an affiliate business record is different from implementing single sign-on. Use a proper identity provider for shared login.

Custom Affiliate Dashboards Outside WordPress

An external portal can use read endpoints to show approved statistics and write endpoints for controlled operations. Keep API keys on the portal server, never in the visitor’s browser. The portal should authenticate the affiliate, translate the request into a server-to-server call, and filter the response so the user sees only permitted records.

Do not rely on a hidden affiliate ID in the page as authorization. A user can modify client-side values. The server must map the authenticated portal account to the allowed AffiliateWP affiliate ID and reject cross-account access.

Cache reports carefully. A shared cache key can expose one affiliate’s earnings to another. Use account-specific caching and purge private data when permissions change.

Zapier And Automation Use Cases

AffiliateWP’s Zapier add-on uses API keys and relies on REST API Extended for write actions. It can create, update, or delete affiliates, referrals, visits, creatives, and payouts when an authorized Zap runs. Triggers and actions are different: a trigger sends an event outward, while an action changes AffiliateWP.

Enable only the resource endpoints required by the Zap. Test with a dedicated account and sample records. A misconfigured loop can repeatedly update the same record or create duplicates each time an event returns to WordPress.

Automation does not eliminate review. High-value referrals, payout changes, affiliate deletion, and rate updates should have approval or exception thresholds.

Input Validation And Schema Discovery

Use OPTIONS requests and official endpoint documentation to discover allowed fields, required arguments, data types, and methods. Validate on both the client and server response path. The client should reject impossible values before sending, while WordPress remains responsible for authorization and schema enforcement.

Never build database queries by concatenating request data. Use the supported REST endpoint and AffiliateWP functions. Sanitize free text, verify numeric IDs, normalize status values, limit string lengths, and allowlist URLs and contexts where appropriate.

Treat a successful HTTP connection separately from a successful application change. Inspect the HTTP status, AffiliateWP response body, returned object ID, and expected fields. A 200-series response should still be checked for the exact outcome.

Idempotency And Retry Design

External networks fail. A request can complete on WordPress while the response is lost, leaving the caller tempted to retry. Without idempotency, the second request may create a duplicate referral, visit, affiliate, or payout record.

Assign each external event a stable correlation key. Before creating a financial object, query or consult a local mapping store. Save the AffiliateWP object ID only after validating the response. Retries should return the known result or update the existing object, not create another one.

Use exponential backoff for temporary failures and a dead-letter queue for events requiring human review. Do not retry authorization errors indefinitely. A 403 usually requires a capability or credential fix, not more traffic.

Backups, Audit Logs, And Recovery

Write access increases the importance of backups. Create regular database backups and test restoration. Before bulk synchronization or migration, take a dedicated checkpoint and export the affected AffiliateWP IDs.

Audit logs should include the service identity, endpoint, method, target ID, correlation ID, result, and timestamp. Redact the Authorization header, API token, customer personal data, and unnecessary request bodies.

Restoring WordPress can replay old state while external systems retain newer transactions. Pause synchronization during recovery, compare event positions, and reconcile before re-enabling writes.

Rate Limiting And Availability

Protect REST endpoints with reasonable rate limits at the application, firewall, or gateway layer. Allow for legitimate batch work without letting a compromised token overwhelm WordPress or create thousands of records.

Use queues for traffic spikes and process events asynchronously when real-time response is not required. Monitor latency, error percentage, authentication failures, duplicate detection, and queue depth. Alert on unusual delete activity and sudden payout or referral volume.

An IP allowlist can add protection for stable server integrations, but it should complement rather than replace authentication. Cloud services can change outbound addresses, so document and test the network design.

API Error Handling

Missing or incorrect authentication can return a 403 response with a message that the requester is not allowed to perform the action. Confirm the key pair, associated WordPress user, required capabilities, enabled endpoint, and site URL.

A 404 can indicate an incorrect route, disabled permalink or REST configuration, proxy rewrite issue, or missing object ID. Validation errors should be returned to an operator with the field and correlation ID, not silently ignored.

Log enough context to reproduce the problem without storing secrets. Separate permanent errors from temporary server or network failures. Failed financial events should enter a review queue rather than disappear.

Security Testing Checklist

1. Confirm the entire API path uses valid HTTPS and redirects do not expose authorization headers.
2. Generate a dedicated key for a minimal-capability service user and verify that unrelated endpoints are denied.
3. Enable only required create, update, and delete endpoint groups.
4. Test invalid IDs, forbidden cross-account access, malformed values, oversized input, replayed events, and duplicate transaction references.
5. Verify that logs and monitoring redact tokens, passwords, personal data, and full Authorization headers.
6. Rotate the test key and prove that the old credential immediately stops working.
7. Restore a backup in staging and rehearse synchronization recovery without duplicating records.

Run the checklist again after WordPress, AffiliateWP, PHP, firewall, proxy, or authentication changes. Security is a property of the complete integration, not just the add-on ZIP.

Recommended Installation And Deployment

1. Document the data flow, authoritative systems, required resources, allowed methods, and business approval steps.
2. Back up WordPress and create an isolated staging environment with nonproduction AffiliateWP data.
3. Install AffiliateWP REST API Extended v1.2.1 and verify compatibility with the exact core AffiliateWP and PHP versions.
4. Enable only the required endpoint operations in AffiliateWP settings.
5. Create a staging API key for a dedicated integration user and store it in a protected secret location.
6. Use OPTIONS and official documentation to build typed request and response validation.
7. Test CRUD actions, permissions, duplicates, retries, deletion safeguards, logging, and backup recovery.
8. Deploy gradually, monitor every write, and rotate the initial production key after the integration is accepted.

Do not test destructive endpoints with real affiliate or payout history. Use synthetic staging records and explicit IDs.

Version 1.2.1 And Compatibility Notes

Public listings date REST API Extended v1.2.1 to November 2023. Because the add-on interacts with AffiliateWP’s internal objects and the WordPress REST framework, compatibility should be checked against the current core version before production use.

Later packages may exist, and endpoint schemas or authentication expectations can change. This does not make v1.2.1 unusable on every site, but it means the business should not assume current compatibility from the product name alone.

Pin the tested version matrix in deployment documentation. Upgrade on staging, compare OPTIONS schemas, run contract tests, and check whether any external client depends on a field or status that changed.

Using The API With Recurring Referrals

An external subscription platform may use the referrals endpoint to mirror commission events, but this can overlap with AffiliateWP Recurring Referrals v1.9.2 if the same payment is also processed by a supported WordPress integration. Decide which component owns each renewal event.

Never let both a webhook integration and a custom API client create the same referral without shared idempotency. Use the external payment or subscription ID as the correlation reference and reconcile the result before payout.

Who Should Use REST API Extended

The add-on is best suited to development teams with a defined integration requirement: external checkout referral creation, CRM synchronization, multi-site account management, a private custom dashboard, controlled creative publishing, or workflow automation.

It is unnecessary for a site that only needs standard AffiliateWP administration and supported local integrations. Enabling remote write access without an application to use it expands the attack surface without providing value.

Browse other tools in the WordPress Plugins Collection, but keep the architecture small. A custom API should be introduced because it solves a documented data-flow problem, not simply because endpoints are available.

GPL Download And Support Notes

The AffiliateWP REST API Extended v1.2.1 download from GPLCare provides plugin files for WordPress users working under the applicable GPL distribution model. Original developer account access, license-key services, automatic updates, private support, or custom integration development may not be included.

Contact GPLCare regarding the downloadable archive supplied here. Consult AffiliateWP’s official REST documentation for current endpoints, methods, schemas, and authentication behavior. A developer should review production integrations that can create, alter, or delete financial records.

Frequently Asked Questions

Does REST API Extended Work Without AffiliateWP?

No. It extends the AffiliateWP REST API and requires a compatible AffiliateWP installation.

What Does The Add-On Add?

It adds create, update, and delete operations for affiliates, creatives, referrals, visits, and payouts, complementing the core read endpoints.

How Are Requests Authenticated?

AffiliateWP uses user-specific API keys consisting of a Public Key and Token through Basic Authentication. Always send them over HTTPS.

Can I Create Referrals From A Non-WordPress Store?

Yes. A trusted server can create referrals after validating external orders, attribution, amount, affiliate status, and duplicate references.

Can A Payout Endpoint Send Real Money?

Creating a payout record is not automatically the same as transferring funds. Use and reconcile a supported payment provider workflow.

Can I Put The API Token In JavaScript?

No. Keep privileged credentials on a secure server. Browser and mobile application code can be inspected by users.

How Do I Prevent Duplicate Referrals?

Use a stable external transaction ID, check existing mappings, store the returned AffiliateWP ID, and design idempotent retries.

Should I Enable Every Endpoint?

No. Enable only the methods and resources the integration needs. Disable delete access unless a reviewed workflow requires it.

Can I Use It With Zapier?

Yes. AffiliateWP’s Zapier add-on uses REST API Extended for write actions. Protect the API keys and test automation loops.

Is Version 1.2.1 The Latest Release?

Public listings associate v1.2.1 with November 2023, and later packages may be available. Verify current compatibility before production use.

Final Verdict

AffiliateWP REST API Extended v1.2.1 turns AffiliateWP’s remote interface into a complete data-management layer for affiliates, creatives, referrals, visits, and payout records. It can connect custom commerce, CRM, reporting, automation, and portal systems to WordPress through documented REST routes.

The same write capability that makes it useful also makes careful engineering mandatory. Use HTTPS, dedicated keys, minimal permissions, selective endpoints, server-side secrets, schema validation, idempotent financial events, audited deletion, monitoring, backups, and staged contract tests. With those controls, the add-on can support sophisticated AffiliateWP integrations without turning remote access into an unmanaged risk.