Objective

Automatically activate or deactivate user access on an external platform based on the subscription lifecycle in EVO.

Endpoint

This use case primarily depends on events via webhook and additional queries to the sales, memberships, and receivables endpoints of the API.

Requirements

sale and recurring webhooks: Must be configured to notify whenever a new sale or renewal occurs.

cancellation webhooks: Must be configured to notify immediate or scheduled cancellations of memberships.

overdue balance clearance webhook: Must be configured to notify when an overdue debt is settled.

sale identifier: Necessary to query the complete sale data when the event returns idSale.

membership identifier: Necessary to query the membership data when the event returns idMemberMembership.

user email: Necessary to link the external platform user with the management platform registration.

Step by Step

1. Configure the necessary webhooks

Also register cancellation and financial settlement events to reflect changes in subscription status.

Recommended events:

NewSale

RecurrentSale

CancelMembership

ScheduleCancelMembership

ClearedDebt

2. Handle sale and renewal events

When a new sale or renewal occurs, the external system will receive a webhook with the sale identifier.

Store the received idSale for later queries.

3. Query the sale details

Use the idSale received in the webhook to query the complete sale details.

In the sale response, locate the member object and obtain the necessary data for integration.

Important data for the flow:

idMember

email

sale data

associated receivables data

4. Identify the user on the external platform

Use the email returned in the member object to locate the corresponding user on the external platform.

If the user does not exist, follow the strategy defined by your system for creation, invitation, or activation.

5. Activate access

When the sale or renewal is valid, activate the user's access on the external platform.

If necessary, send an activation communication, invitation, or first access link.

6. Handle cancellation events

When a membership cancellation occurs, either immediate or scheduled, the system will receive a webhook containing idMemberMembership.

Use this identifier to query the membership data.

Based on the status and rules of your system, deactivate access immediately or schedule deactivation for the correct date.

7. Handle overdue balance clearance

When the ClearedDebt event occurs, query the sale again based on the returned idSale.

Check the receivables associated with the sale and confirm the financial status of the member.

If the settlement restores the right to use, reactivate access on the external platform.

8. Validate financial status before activating or maintaining access

When querying the sale, use the receivables object to assess the payment situation.

Consider the possible financial statuses:

1 = Open

2 = Received

3 = Canceled

4 = Overdue

Important:
The activation, blocking, or reactivation rule must consider the commercial and financial policy adopted by the integration.

Example Flow

A user makes or renews a plan on the management platform.

A sale or renewal webhook is triggered to the external system.

The external system receives the idSale.

The system queries the sale details.

The system obtains the idMember and the user's email.

The system links with the user on the external platform.

The system activates access and sends an activation communication, if applicable.

If a relevant cancellation or delay occurs in the future, new events update this access.

Frequently Asked Questions

1. What events should be registered in the webhook?

For the complete flow, it is recommended to use events for:

completed sale

recurring renewal

membership cancellation

scheduled cancellation

overdue balance clearance

2. How to obtain user data after receiving the webhook?

When the webhook returns idSale, query the sale details.

When it returns idMemberMembership, query the membership details.

3. How to locate the user on the external platform?

The most common identifier for linking is the email returned in the member data.

4. Should access be deactivated on any cancellation?

This depends on the business rule of the integration.

In scheduled cancellations, it may be necessary to maintain access until the effective termination date.

5. What to do when an overdue payment is settled?

Use the overdue balance clearance event to review the financial situation and, if applicable, reactivate access.

Expected Outcome

If all steps are followed correctly:

new subscriptions and renewals will automatically activate access;

cancellations will deactivate or schedule the deactivation of access;

financial settlements will allow reassessment and restoration of access when applicable.

Final Tips

Always query the complete sale or membership data after the webhook.

Do not make decisions based solely on the received event; use complementary endpoints to confirm the current state.

Centralize the activation and deactivation logic in a single rule in the external system.

Handle duplicate webhook events with idempotency.

Log processing for auditing and reprocessing.

Support

If you have questions about available events, webhook payloads, or query endpoints, consult the documentation.

User access control via external service

Objective#

Endpoint#

Requirements#

Step by Step#

1. Configure the necessary webhooks#

2. Handle sale and renewal events#

3. Query the sale details#

4. Identify the user on the external platform#

5. Activate access#

6. Handle cancellation events#

7. Handle overdue balance clearance#

8. Validate financial status before activating or maintaining access#

Example Flow#

Frequently Asked Questions#

1. What events should be registered in the webhook?#

2. How to obtain user data after receiving the webhook?#

3. How to locate the user on the external platform?#

4. Should access be deactivated on any cancellation?#

5. What to do when an overdue payment is settled?#

Expected Outcome#

Final Tips#

Support#