DEV Community: UnifyPort

Third-Party AI Assistants on WhatsApp in the EU: What Changed in 2026

unifyport — Thu, 23 Jul 2026 05:55:23 +0000

On June 9, 2026, the European Commission ordered Meta to restore free WhatsApp access for competing general-purpose AI assistants while its antitrust investigation continues.

That sounds simple, but the headline is easy to overread.

The measure does not mean that every third-party assistant is automatically available on every WhatsApp account. It is regional, temporary, and focused on a specific distribution path: competing general-purpose AI assistants using the WhatsApp Business API.

The short answer

Can third-party AI assistants use WhatsApp in Europe again?

Yes, under the interim conditions ordered by the European Commission—but actual availability still depends on the provider, region, onboarding status, and account eligibility.

The order requires Meta to restore the access conditions that applied before October 15, 2025, including free access, and to maintain them until the Commission reaches a final decision.

It does not:

Create Business API credentials for a provider
Complete Meta app review
Approve individual WhatsApp accounts
Guarantee worldwide access
Apply automatically to every type of business chatbot
Represent a final finding that Meta violated competition law

The timeline

The distinction between policy, access, fees, and interim enforcement becomes clearer when viewed as a timeline.

Date	Event	Practical meaning
October 15, 2025	Meta adopted a policy restricting competing general-purpose AI assistants from using the WhatsApp Business API	Rival assistants lost the previous distribution path
December 2025	The European Commission opened an antitrust investigation	Meta's policy entered formal competition review
March 4, 2026	Meta readmitted third-party general-purpose assistants but introduced a fee	Access returned, but the Commission preliminarily considered the fee equivalent to the earlier restriction
June 9, 2026	The Commission imposed interim measures	Meta was ordered to restore the previous free-access conditions
Five working days later	Compliance deadline specified by the Commission	Meta was required to implement the temporary remedy
Final decision	Still pending	The underlying antitrust investigation remains open

An interim measure protects competition while an investigation continues. It changes what Meta must do now, but it does not predetermine the final legal outcome.

Which type of “WhatsApp AI” are we discussing?

The phrase “WhatsApp AI” can describe several unrelated products and architectures.

Product or integration	Covered directly by the EU measure?
A competing general-purpose AI assistant distributed through the WhatsApp Business API	Yes—this is the core subject
A business-specific support bot answering questions about one company	Not necessarily; its terms and permissions may be different
Meta AI	No; this is Meta's own assistant
Meta Business Agent	No; this is another Meta product
An internal workflow that sends inbound customer messages to an AI model	This is a separate integration decision
A third-party assistant outside the European market	No automatic conclusion should be drawn

This distinction matters because the legal measure concerns access to a distribution channel. It does not define the technical availability of every chatbot, account, or region.

Why might an assistant still be unavailable?

Even after the interim measure, a third-party assistant may still be unavailable for several reasons:

The provider has not completed restored Business API onboarding.
The provider has not reopened registration in the target region.
The user or business account is outside the relevant rollout.
The account does not meet Meta's current eligibility requirements.
The integration belongs to a different product category.
App review, business verification, or permissions are incomplete.
The provider has restored its public assistant but not the related webhook or operational controls.

A legal order does not automatically create credentials, deploy code, configure webhooks, or approve an account.

A verification checklist for engineering teams

Before changing a production integration, verify each layer independently.

1. Confirm the region

Record:

Where the AI provider is established
Where the service is being offered
Where the WhatsApp user or business account is located
Whether the provider describes the rollout as EU, EEA, or global

Do not treat a European competition remedy as a global product announcement.

2. Name the product precisely

Determine whether the integration is:

A general-purpose AI assistant
A business-specific customer-support agent
Meta AI
Meta Business Agent
A Cloud API application
A BSP-managed integration
An internal message-processing workflow

These products do not necessarily use the same access or approval path.

3. Ask the provider for current operational status

Confirm:

Whether Business API access has been restored
Whether new onboarding is open
Which regions are active
Which accounts are eligible
Whether pricing has changed
Whether the provider has published a migration notice
Whether existing users need to reconnect

The Commission's decision is authoritative for the competition measure. The provider remains the authoritative source for its own rollout.

4. Retest the complete workflow

Do not stop after confirming that an assistant profile is visible.

Test:

User consent
Incoming messages
Webhook delivery
Conversation state
Model invocation
Human handoff
Reply delivery
Logging and retention
Account disconnect and recovery

A working profile page does not prove that the operational integration is healthy.

Keep the architecture reversible

Platform policies, regional rollouts, fees, and account rules can change independently.

A more resilient architecture separates the major stages:

WhatsApp message
       |
       v
Message intake
       |
       v
Consent and policy checks
       |
       v
Conversation storage
       |
       +------------------+
       |                  |
       v                  v
AI model              Human queue
       |                  |
       +--------+---------+
                |
                v
          Reply delivery

This separation provides several advantages:

The message history does not belong exclusively to one model.
A human agent can take over without losing context.
The AI provider can be replaced without rebuilding message intake.
Regional policies can be applied before model invocation.
Reply delivery can be disabled independently during an incident.
Audit logs can distinguish automated and human responses.

The legal right of a provider to access WhatsApp and the technical design of a company's support workflow are related, but they are not the same decision.

Common interpretation mistakes

“The WhatsApp AI ban has been permanently cancelled”

Not confirmed.

The Commission imposed interim measures while the investigation continues. A final decision has not yet been reached.

“Every third-party assistant should now work”

Not necessarily.

The provider still needs operational access, regional rollout, appropriate credentials, and eligible accounts.

“The measure applies worldwide”

Do not assume that.

The decision addresses competition in the European market and should not be treated as a global availability guarantee.

“Meta AI availability proves that competitors are available”

No.

Meta AI is a Meta product. Its rollout does not demonstrate that a competing provider has completed Business API onboarding.

“A customer-support chatbot is automatically covered”

Not always.

The measure focuses on competing general-purpose AI assistants. A business-specific support agent may be governed by different product terms and permissions.

What teams should document

For every affected integration, record:

Provider name
Product category
WhatsApp access method
Target region
Business verification state
App-review state
Required permissions
Webhook configuration
Human handoff behavior
Current pricing terms
Provider confirmation date
Last successful end-to-end test

This creates a verifiable operational record instead of relying on a news headline or assumptions about account eligibility.

Final takeaway

The 2026 EU interim measures are important, but their scope is narrower than “third-party WhatsApp AI is available again.”

The accurate interpretation is:

The European Commission ordered Meta to restore free WhatsApp Business API access for competing general-purpose AI assistants.
The restored conditions apply while the antitrust investigation continues.
The measure is not a final judgment.
Actual availability still depends on provider rollout, onboarding, region, and account eligibility.
Engineering teams should retest the entire message workflow before changing production routing.
Message intake, AI reasoning, human handoff, and reply delivery should remain separable.

Treat the Commission's announcement as a policy and access change—not as proof that a particular assistant or account is production-ready.

Official sources

Originally published on UnifyPort.

This article provides a technical and product interpretation, not legal advice. It was prepared with AI assistance for language and structure, then reviewed and fact-checked against the cited official sources.

Recover Missed LINE MINI App Purchase Webhooks with a 7-Day Reconciliation Job

unifyport — Wed, 22 Jul 2026 09:02:38 +0000

A successful LINE MINI App purchase reservation does not mean that the customer completed the payment.

The final source of truth is the purchaseComplete webhook. But what happens when your endpoint is unavailable, a deployment breaks webhook processing, or the event reaches your server but the business transaction fails?

LINE provides an event history API that can recover purchase webhooks from the previous seven days. The recovery process still needs careful pagination, reconciliation, and idempotency to avoid granting the same item twice.

Reservation success and purchase completion are different events

LINE MINI App in-app purchases use a multi-step flow.

Your server first reserves the purchase:

POST https://api.line.me/iap/v1/product/reserve

LINE returns an orderId, but the customer can still:

Close the MINI App
Cancel the app-store payment
Lose network connectivity
Fail to finish the payment flow

The digital item or entitlement should therefore be granted only after processing a purchaseComplete event.

These are four separate questions:

Question	Evidence to trust
Did the reservation succeed?	Reserve response, saved `orderId`, and `x-line-request-id`
Did the purchase complete?	A `purchaseComplete` event
Did the live webhook reach your endpoint?	Raw request log and webhook-processing record
Was the entitlement granted exactly once?	An idempotency record keyed by `orderId`

Store recovery data when reserving the purchase

A recovery job cannot reconcile an order if the reservation was never recorded.

Store at least:

Your internal checkout ID
LINE's orderId
The x-line-request-id response header
Reservation timestamp
Expected product or entitlement
Current purchase state
Whether a purchaseComplete event has already been applied

Alert when a reservation remains unresolved beyond the expected checkout duration.

Do not mark it as paid automatically, and do not wait until the seventh day to investigate. The event history API only covers the preceding seven days.

Query a fixed recovery window

Use the official event history endpoint:

curl --get "https://api.line.me/iap/v1/webhook/events" \
  -H "Authorization: Bearer ${LINE_CHANNEL_ACCESS_TOKEN}" \
  --data-urlencode "startEpochSeconds=1784678400" \
  --data-urlencode "endEpochSeconds=1784700000" \
  --data-urlencode "pageSize=100" \
  --data-urlencode "status=FAILED"

The timestamps above are example values for a window on July 22, 2026. Generate UTC epoch seconds from the actual incident start and end times.

The status filter describes webhook delivery:

FAILED: LINE could not successfully deliver the webhook
SUCCESS: LINE successfully delivered it

It does not describe whether the customer's payment succeeded or failed.

When the problem occurred after your endpoint accepted the request, querying only status=FAILED may not be sufficient. In that case, omit the filter and reconcile every event within the incident window.

Keep pagination parameters stable

The history endpoint returns at most 100 records per page and may include a nextCursor.

For every subsequent page, keep these values unchanged:

startEpochSeconds
endEpochSeconds
pageSize
status

Only the cursor should change.

const baseUrl = "https://api.line.me/iap/v1/webhook/events";

const fixedQuery = {
  startEpochSeconds: "1784678400",
  endEpochSeconds: "1784700000",
  pageSize: "100",
  status: "FAILED",
};

let cursor;

do {
  const query = new URLSearchParams(fixedQuery);

  if (cursor) {
    query.set("cursor", cursor);
  }

  const response = await fetch(`${baseUrl}?${query}`, {
    headers: {
      Authorization: `Bearer ${process.env.LINE_CHANNEL_ACCESS_TOKEN}`,
    },
  });

  if (!response.ok) {
    throw new Error(
      `LINE event history request failed: ${response.status}`,
    );
  }

  const page = await response.json();

  for (const record of page.events) {
    if (record.event.type === "purchaseComplete") {
      await applyPurchaseOnce(
        record.event.orderId,
        record.event,
      );
    }
  }

  cursor = page.nextCursor ?? undefined;
} while (cursor);

Changing the time range or filters during pagination can create overlaps or gaps in the recovery result.

Use the same handler for live and recovered events

Do not create a separate entitlement implementation exclusively for recovered events.

Both paths should call the same business handler:

Live webhook ────────┐
                     ├── applyPurchaseOnce(orderId, event)
Event history API ───┘

The handler should atomically:

Insert an idempotency record keyed by orderId
Stop if that key already exists
Validate the expected product and order state
Grant the entitlement
Mark the purchase as completed
Commit everything in one transaction

If the live webhook was already applied, the recovered event should become a no-op.

Conceptually:

async function applyPurchaseOnce(orderId, event) {
  return database.transaction(async (transaction) => {
    const inserted = await transaction.insertIdempotencyKey(orderId);

    if (!inserted) {
      return {
        status: "already_applied",
        orderId,
      };
    }

    await transaction.grantEntitlement({
      orderId,
      productId: event.productId,
    });

    await transaction.markPurchaseCompleted(orderId);

    return {
      status: "applied",
      orderId,
    };
  });
}

The exact database API will differ, but the idempotency record and entitlement update must share the same transaction boundary.

Reconcile four sources of evidence

For a fixed incident window, compare:

Reserved orderId values that remain unresolved
Live webhook request and processing logs
Event history records returned by LINE
Idempotency and entitlement records in your database

Classify every reservation as one of:

Completed and applied
Completed but already applied
Incomplete or canceled
Missing and requiring manual investigation

Record the following information in the incident report:

Exact UTC start and end timestamps
Applied filters
Number of pages processed
Number of events examined
Recovered orderId values
Duplicate events skipped
Last successful recovery time

Continue verifying live webhook signatures

The history API uses a channel access token. It does not recreate the original HTTP webhook request and should not be expected to contain its original signature header.

For live deliveries, continue verifying LINE's x-line-signature against the raw request body using the channel secret.

Do not parse and serialize the JSON again before verification. Signature validation must use the exact raw bytes received by the endpoint.

Recovered history events should be marked with a source such as:

{
  "source": "line_event_history",
  "orderId": "example-order-id"
}

This makes audit logs distinguishable without introducing a second entitlement path.

Important limitations

The event history API is a recovery source, not a replacement for live webhook monitoring.

Keep these boundaries in mind:

The lookback period is seven days, not a permanent ledger
Each page returns at most 100 records
status=FAILED reports delivery failure, not purchase failure
A successfully delivered webhook may still fail inside your application
Recovered events may duplicate events already processed live
Refund history may follow a different API lifecycle
Your own reservation and entitlement records must be retained longer than seven days

Schedule reconciliation frequently enough that a weekend outage cannot age out of the recovery window.

Recovery checklist

Before running the job:

[ ] Confirm the exact UTC incident window
[ ] Save the original query parameters
[ ] Confirm the channel access token is available server-side
[ ] Back up or snapshot the unresolved reservation list
[ ] Verify that applyPurchaseOnce is idempotent

While processing:

[ ] Keep filters unchanged across pages
[ ] Change only cursor
[ ] Process only expected event types
[ ] Deduplicate by orderId
[ ] Record recovered and skipped orders
[ ] Stop on authentication or schema errors

After processing:

[ ] Reconcile every reservation in scope
[ ] Confirm entitlements were granted exactly once
[ ] Record the last successful recovery checkpoint
[ ] Investigate records that remain unclassified
[ ] Confirm live webhook monitoring is healthy again

Final takeaway

A successful purchase reservation is not proof of payment, and a missed live webhook does not need to become a permanent lost order.

A reliable recovery workflow should:

Query LINE's event history before the seven-day boundary
Keep the incident window fixed during pagination
Replay purchaseComplete events through the live business handler
Use orderId as the idempotency key
Reconcile reservations, deliveries, and entitlements before closing the incident

The history endpoint helps recover the event. Your own durable records and idempotent transaction determine whether recovery is safe.

Official references

Originally published on UnifyPort.

This article was prepared with AI assistance for language and structure, then technically reviewed and verified by the author.

How LINE MINI App Service Notification Tokens Work (and Why You Must Rotate Them)

unifyport — Tue, 21 Jul 2026 08:36:35 +0000

LINE MINI App service messages are not ordinary push notifications.

They use a user-bound, action-specific notification token that changes after every successful send. If your application keeps using the original token, later reminders can fail even when the template and channel credentials are correct.

This guide explains the complete flow: issuing the token, sending an approved template, saving the renewed token, and handling retries safely.

Prerequisites

Before implementing the API flow, make sure:

Your LINE MINI App is verified for production use.
The service-message template has been approved.
The message confirms or responds to an action completed by the user.
The channel access token is stored only on your server.

Unverified MINI Apps can test service messages in a Developing channel, but they cannot send production service messages from a Published channel.

Understand the three tokens

Three different credentials are involved in the flow.

Credential	Purpose	Important lifecycle rule
LIFF access token	Identifies the current LINE user	Exchange it shortly after the user completes the action
Channel access token	Authorizes server-side LINE API calls	Never expose it to the browser
Service notification token	Authorizes notifications for one user action	Replace it after every successful send

A LIFF access token can be obtained in the MINI App with:

const liffAccessToken = liff.getAccessToken();

Send this value to your backend over HTTPS after the reservation, purchase, check-in, or other approved action succeeds.

Do not write the LIFF access token or service notification token to application logs.

Step 1: Issue a service notification token

Your backend exchanges the LIFF access token for a service notification token:

curl -X POST https://api.line.me/message/v3/notifier/token \
  -H "Authorization: Bearer ${LINE_CHANNEL_ACCESS_TOKEN}" \
  -H "Content-Type: application/json" \
  -d "{\"liffAccessToken\":\"${LIFF_ACCESS_TOKEN}\"}"

A successful response looks like this:

{
  "notificationToken": "34c11a03-b726-49e3-8ce0-949387a9f531",
  "expiresIn": 31536000,
  "remainingCount": 5,
  "sessionId": "xD06R2407210008"
}

Store the following values:

notificationToken
expiresIn
remainingCount
sessionId
Your internal order, reservation, or action ID

The token is bound to one user and one action session. It is not a reusable user identifier.

One LIFF access token can issue only one service notification token, so perform the exchange once and persist the result.

Step 2: Send an approved template

Use the service notification token with the official send endpoint:

curl -X POST "https://api.line.me/message/v3/notifier/send?target=service" \
  -H "Authorization: Bearer ${LINE_CHANNEL_ACCESS_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "templateName": "thankyou_msg_en",
    "params": {
      "date": "2026-07-21",
      "username": "Brown & Cony"
    },
    "notificationToken": "34c11a03-b726-49e3-8ce0-949387a9f531"
  }'

A few details are easy to miss:

target=service is required.
templateName must exactly match an approved template.
The keys inside params must match the variables defined by that template.
If the template has no variables, params is still required and should be {}.

Step 3: Save the renewed token

This is the most important implementation rule:

After every successful send, replace the stored notification token with the new token returned by LINE.

The response contains an updated token and counters:

{
  "notificationToken": "renewed-token-value",
  "expiresIn": 31536000,
  "remainingCount": 4,
  "sessionId": "xD06R2407210008"
}

Do not schedule another reminder until the renewed token has been saved successfully.

A safe sequence is:

Lock or version the action record.
Send the approved service-message template.
Receive the successful response.
Replace the stored notification token.
Update remainingCount and expiresIn.
Commit the database transaction.
Schedule the next reminder.

This prevents two workers from sending with the same token concurrently.

Example storage model

A minimal action record could look like this:

{
  "actionId": "order_12345",
  "sessionId": "xD06R2407210008",
  "notificationToken": "encrypted-token-value",
  "remainingCount": 4,
  "expiresAt": "2027-07-21T10:00:00Z",
  "version": 2
}

Encrypt the notification token at rest and use the version field—or an equivalent database lock—to prevent concurrent updates.

Handling errors and retries

Treat notification tokens as rotating credentials, not permanent addresses.

HTTP 400

Check:

Request body format
Template name
Template variables
Recipient state
Current notification token

Do not repeatedly retry the same invalid request.

HTTP 401

Refresh or verify the server-side channel credential.

If the LIFF access token or service notification token is invalid, start a new eligible user-action flow instead of replaying it indefinitely.

HTTP 403

Confirm:

The channel is authorized for the operation
The MINI App has the required status
The template exists and is approved

Concurrent sends

Never allow two workers to spend the same notification token simultaneously. Use a database lock, compare-and-swap update, or version check around the send operation.

Message limits

A newly issued token is normally valid for up to one year and starts with a limited number of sends.

The reviewed use case may have a different limit, so your application should always treat the latest remainingCount returned by LINE as the runtime source of truth.

Service messages must remain tied to the original user action. They are designed for cases such as:

Reservation confirmations
Order results
Shipping updates
Reminders related to the original action

They are not intended for:

Advertising
Coupons
Product promotions
General announcements
Free-form customer support conversations

Implementation checklist

Before releasing the integration, verify:

[ ] The LIFF access token is collected after an eligible user action
[ ] Token exchange happens on the server
[ ] Channel credentials are never exposed to the browser
[ ] Tokens are not written to application logs
[ ] The exact approved template name is used
[ ] target=service is included
[ ] The renewed notification token is saved after every send
[ ] remainingCount is checked before scheduling another message
[ ] Concurrent sends are prevented
[ ] Failed requests use bounded, reason-specific retry logic

Conclusion

The API calls themselves are straightforward. The difficult part is managing the notification token correctly.

Think of it as a rotating credential associated with one user action:

Obtain a fresh LIFF access token.
Exchange it on the server.
Send an approved template.
Save the renewed notification token.
Use the latest remainingCount for future decisions.

If you get the rotation and concurrency rules right, follow-up service messages become much more predictable.

Sources

Originally published on UnifyPort.

This article was prepared with AI assistance for language and structure, then technically reviewed and verified by the author.