Article summary
Integrate AIPUSH RCS Number Checking without claiming an API, using batch manifests, TXT input, Excel staging and idempotent write-back.
AIPUSH RCS Number Checking currently uses a file exchange: the enterprise uploads TXT and exports Excel after the task. It is not a direct screening API integration. The correct enterprise architecture therefore does not invent a real-time endpoint. It creates a traceable, retryable batch channel between CRM, an operator and controlled write-back.
Separate the workflow into four boundaries
The source system selects contacts permitted for processing. An exporter creates the phone-only TXT and batch manifest. The operational step submits the task and retrieves Excel. An importer validates the result in staging before CRM write-back. batch_id connects the boundaries, and no failed step modifies the master contact directly.
Choose RCS Validity or RCS System first
| AIPUSH task | Returned fields | Question it fits | Do not claim |
|---|---|---|---|
| RCS Validity | Phone, registration/availability status | Create an RCS channel candidate | Every device feature is supported |
| RCS System | Phone, system, ID | Organize a system result for an approved purpose | Carrier, handset model or permanent capability |
The batch manifest is the control plane
A manifest should contain batch_id, task_type, source_snapshot, created_at, row_count, unique_count, file_hash, owner and purpose. The TXT itself contains one phone per line and no names, orders or permission records. The manifest proves that the returned Excel belongs to the intended task and source snapshot.
Validate in staging before touching CRM
Excel first lands in rcs_screening_staging. Check required columns, types, duplicate rows, unknown states and expected counts. Then create a change preview: new observations, changed observations, conflicts and no-ops. The operator approves this difference set rather than an import button that overwrites an entire contact table.
Use idempotency keys for safe re-imports
A unique key can combine batch_id, input_row_id, task_type and result_version. Importing the same result again returns already_processed and creates no duplicate history. A corrected workbook enters with a new result_version. Network interruption or a repeated click then cannot apply the same observations twice.
Google capability checks and file screening are different systems
Google’s RCS for Business capability-check documentation describes agents, regional endpoints, E.164 phones and capability/reachability semantics. Bulk checks also have single-region and cache-freshness constraints. An enterprise must not present AIPUSH Excel columns as Google API responses or use one availability field as a substitute for the messaging agent’s actual capability decision.
The 2026 regional change shows why semantics matter
Google’s release information says regional endpoints became mandatory for batch capability checks in 2026 and that mixed-region requests return 400. Even when an organization does not call that API, the change illustrates that an RCS observation depends on provider, region, agent launch and method. Store provider, task_type and checked_at rather than one ambiguous rcs=true.
Make the error queue exportable
Separate format_error, missing_result, duplicate_input, unexpected_field, row_count_mismatch and manual_review. Only repairable phone exceptions produce a new exception TXT; other defects return to the file or configuration layer. A small failed subset should not force a rerun of the full population.
Write provenance and expiry beside the result
Along with the observed value, store screening_provider, screening_task, checked_at, expires_at, batch_id and review_state. Downstream systems check expiry before use. RCS status can change with device, configuration, carrier and service environment; it is not a permanent customer attribute.
Channel decisions still need permission and fallback rules
A candidate channel is not permission to send. The messaging system must also read consent, message category, stop state and business purpose. If SMS is a fallback when RCS is unavailable, prevent duplicates and trigger fallback from actual send/delivery events—not immediately from an empty screening cell.
The smallest reliable production design
- A read-only source snapshot and TXT exporter.
- An immutable batch manifest and file hash.
- An operator submission/download log.
- Excel staging and acceptance rules.
- Difference preview, approval and idempotent write-back.
- Expiry, withdrawal, audit and deletion jobs.
This architecture does not pretend that AIPUSH provides an RCS screening API. It still produces a reliable enterprise integration because every file, field, decision and write can be traced from CRM back to one batch.
