TM Forum Community

Hello Team,

I currently have a custom API that allows users to upload an Excel/CSV file containing telephone numbers.

In our current implementation, the file is uploaded and stored in our system immediately. Once the upload is successful, we return a success response to the user. The actual processing of the file (reading the numbers, validation, and importing them into the inventory) happens asynchronously in the backend after the upload is completed.

As part of our TM Forum Open API alignment initiative, I would like to understand which TMF Open API is the most appropriate for this use case.

The functionality includes:

• Uploading an Excel/CSV file containing multiple telephone numbers.

• Storing the uploaded file in the system.

• Returning a successful upload response to the user.

• Processing the file asynchronously in the backend.

• Creating/importing telephone numbers into the inventory after processing.

Could you please advise which TMF Open API should be used for this scenario? Is there a TMF standard approach for handling file uploads with asynchronous processing and bulk telephone number imports?

Thank you for your guidance.

Chirag's got the shape right - TMF639 as the system of record for the numbers, and a job resource that takes the file, returns 202, and creates the resources asynchronously. That's the correct spine. What decides whether this survives a real 50k-number upload is everything between the 202 and the "done", and the spec is silent on all of it.

Partial failure is the normal case, not the exception. A sheet of 50,000 numbers will have some already in inventory, some malformed, some reserved elsewhere. A success on the upload only means the file was accepted - the job has to carry a per-row outcome (imported / duplicate / invalid / rejected-with-reason) the user can pull back, or you get "I uploaded 50k, why do I have 49,981?" tickets nobody can answer. Model the job with a result set, not just a status.

Idempotency on the file, not just the request. Users re-upload the same sheet the moment the first attempt looks stuck. Key the job on a content hash so a re-submit returns the original job instead of importing every number twice - TMF639 has no natural unique constraint that will save you here.

State, not existence. A number appearing in TMF639 isn't the same as it being usable. Give each imported resource an honest lifecycle state (received -> validated -> available) so a downstream assignment can't grab a number that's still mid-validation. The gap between "row processed" and "number assignable" is where the 2am incidents live.

And decide up front whether the file is loading available stock or reserving/assigning numbers - that changes whether a failed row is a warning or a hard stop, and whether the job needs to be transactional at all.

One question that usually settles the design: if the same number lands in two concurrent uploads, which one wins, and does the loser get told? That answer tells you whether the job owns a reservation step or just writes to inventory and hopes.