An agency-facing Request Tracking API

[konklone]

We're highly likely to be sending emails to some agencies when requests come in. But we also want to provide the tools for integration that works better for both sides, especially for agencies who prefer or already use a non-email based system.

I had some ideas for this today, and so here's one proposal. There's 3 components to that I can think of, with some possible URLs for them (ignoring an /api/ prefix or subdomain or whatever):

• /requests - A GET here provides requests awaiting an agency. agency access to every single detail.
• /request/:id/status - A PUT here allows an agency to update the status of a request, by a unique identifier. This could be its original tracking number, or other valid identifiers (more on that next).
• /request/:id/tracking - A PUT here allows an agency to add additional tracking identifiers that a request can be referred to with. This allows agencies to manage a crosswalk between our tracking numbers and theirs, on their terms. This endpoint would return a 4XX code if the value was not unique. Whether the ID needs to be unique across all agencies, or across the submitting agency, would need to be decided.

Authentication is clearly needed here, the simplest solution being a shared secret for each integrating agency. How this ties into our set of contacts would need some implementation choices on our part.

[ErieMeyer]

+1

[konklone]

We're a ways off from getting to this point, and when we do get there, it's going to be informed by the architecture we have at the time -- so I'm going to close this in favor of more actionable work in our app repository.