Open APIs

------------------------------
pranay patel
TO BE VERIFIED
------------------------------

Chirag's summary is right – there is no native TMF bulk API, and TMF641 plus an async job pattern is the standards-aligned shape. I would add what tends to break once you are actually running 100k, because most of the cost sits in decisions the spec does not make for you.

Separate the contract from the batch mechanism. A file of 100k numbers is not an order, it is a job. Model it as its own resource that emits standard service orders internally. Do not extend TMF641 to swallow a file – that is what keeps CTK green, because CTK is then still validating the standard surface rather than your extension.

Decide the atomicity unit before anything else. Whole file, chunk, or item? Almost always item. If a single malformed MSISDN can roll back 99,999 good activations, you will find out in production, at 2am. The job then becomes an aggregate reporting layer over item-level outcomes, not a transaction boundary.

Idempotency is what actually bites. Retries in bulk are not an edge case – timeouts happen, and someone will re-upload the same file to be safe. You need a deterministic key per item (an external correlation id) and dedupe at the job boundary. Without it, re-driving a half-failed file silently double-applies call forwarding on the numbers that already succeeded.

Do not poll 100k orders. Return 202 with a job id, then either notification events or a job-level state with a downloadable result set.

Rate-limit at the job processor, not the caller. The constraint is the provisioning layer and the network elements behind it, never the API tier. The job needs to be pausable and resumable, because the constraint moves during the run.

Treat per-item reconciliation output as a deliverable, not as logging. Ops will ask which 37 failed and why, and they will ask within the hour. Every item needs an outcome and a reason code, and failures need to be re-drivable as a subset rather than by re-running the original file.

Two questions back, since they change the answer: is your current 50-item payload synchronous? And is your intended atomicity item-level or file-level? Those two decide whether you need a job resource at all, or just chunked orders behind an orchestrator.

You raised TMF638 async / batch payload support separately – same shape of answer, and worth resolving both the same way so you do not end up with two different bulk idioms in one estate.

Both questions come back to the same distinction: what the API models versus what your platform does. Taking them in turn.

Multiple numbers in one Service request. I'd resist it. A Service resource is one service instance, and the moment it carries N numbers you've made its identity ambiguous - inventory, assurance and billing all inherit that ambiguity downstream, long after activation is a solved problem. For bounded volumes, TMF641 with one order item per number is the honest model: the order is the multi-thing, the service isn't. For 50k, the job resource we discussed emits those orders internally. More plumbing up front, considerably less archaeology later.

The CTK PATCH failure is telling you something true. CTK isn't wrong here; it's finding a real gap. If POST returns a resource that isn't yet PATCHable, that resource has no honest intermediate state. Give it one - acknowledged, or inProgress - and let PATCH be valid immediately, transitioning to active when provisioning completes. Don't make the test pass by blocking on the downstream call. A synchronous wait passes CTK today and becomes the outage on the day the provisioning layer is slow.

Where PATCH genuinely doesn't apply, declare it. Conformance is about stating which operations you implement, not implementing all of them. A documented exclusion is defensible; a PATCH that exists only to satisfy a test isn't.

Async activation is supported - 202, a lifecycle state on the resource, and notification events rather than polling. The specs assume it. What they don't do is tell you which states you need, because that depends on what your ops teams have to see at 2am.

Bulk order via file, accepted synchronously and processed asynchronously - that's the same job pattern, and it aligns provided TMF622 itself never accepts a file. The upload creates a job, the job returns 202 with an id, and the job then creates standard orders. Per-item outcomes come off the job, not off the orders.

So the question I'd ask before any of it: does your Service resource expose a state machine today, or does it go straight from created to active? The PATCH failure suggests the latter, and that will cost you more in assurance than it ever will in CTK.

Hi Pranay,

It is worth considering whether you need order management for this, or whether it is straight activation or provisioning.

If you don't need order management (and all that this entails) - then TMF640 (Service Activation), or TMF702 (Resource Activation), or even TMF664 (Resource Function Activation) might be more appropriate to use.

Chirag is correct - there is no support for 'bulk' operations in the TMF standards - they are all 'transactional' standards - and do not provide any file/bulk based interfaces.

Your best approach would be to put a pre-processor in front of the TMF interfaces to submit the requests. Most accept multiple requests at once but that comes with some notable complications if, as I surmise from the responses, there might be dependencies between items. Besides having to think about the dependencies in doing multiple services in a single request there are also optimisation of scale in each request. It may be that only performance and scaling can inform you in your architecture what an optimum number of services is in each request - regardless of which interface you use.