A build is sending the client's events somewhere. A webhook, a callback URL, a sink, a notify-this-endpoint the deploy created so a test could finish. Tonight, three proofs, and you do them in an account you or the client administer. List that destination, including which events it receives. Change it to an address you hold. Then prove a new event arrives at the new address, and does not arrive at the old one — or write, in the same note, that you cannot see the old one. If the list, the change, or the proof needs the partner's login, the flow is still theirs. Your name is on the product the events are about.
This is the destination. It is not the credential the build minted. Listing a key, revoking it, and proving the old value fails is revoke the key they minted. Rotating a key the application uses does not move a subscription that posts to someone else's URL with a different secret, and a subscription you never listed will keep posting after the key you knew about is dead. It is also not the afternoon you decide whether a new vendor may read the client's text. Before a tool reads the client's text is the account you open before the first document is sent. An address that has been receiving events since last Tuesday is the document that already left. And it is not the day-one decision of which human may enter which system. What access to give a subcontractor is a register of people. A URL is not a person. The register will not show it.
The blindspot that matches an unlisted destination is in OWASP's API Security Top 10 for 2023, risk API9:2023, Improper Inventory Management. They separate two failures. A documentation blindspot includes not knowing which environment a host is running in, who should have network access to it, and which version is running, plus missing documentation, no retirement plan, and a host inventory that is missing or outdated. A data-flow blindspot is the one for tonight. An API has one "if there is a 'sensitive data flow' where the API shares sensitive data with a third party and" any of three things is true: "There is not a business justification or approval of the flow," "There is no inventory or visibility of the flow," or "There is not deep visibility of which type of sensitive data is shared." The impact line that sits above that test: threat agents "may get access to sensitive data through a 3rd party with whom there's no reason to share data with" (OWASP, API9:2023 Improper Inventory Management). A callback whose business justification was "the deploy needed a place to send test events," pointed at a URL the partner registered, is that third party. The justification ended when the test ended. The flow did not.
What they say to do is an inventory, not a scan you run once. "Inventory integrated services and document important aspects such as their role in the system, what data is exchanged (data flow), and their sensitivity." The host inventory beside it asks which environment the API is in and who should have network access. A webhook is an integrated service under that instruction even when nobody called it an API in the subcontract. OWASP rates exploitability Easy and prevalence Widespread. Those are their ratings. They are not a count of your subscriptions, and they are not a finding that a federal catalogue applies to a commercial agency. The blanks are the point. If the only inventory anyone can quote is "the partner set up notifications," you have not made the list. You have left the flow unnamed.
How often practitioners say they worry about interfaces they have lost track of is a survey, and it is not a count of webhooks. Salt Security's State of API Security Report, 2024, announced 18 June 2024, combined a survey with anonymized data from Salt's own customers. The release says the research "analyzed survey responses from 250 IT and security professionals," and the methodology line says "survey data from nearly 250 respondents." Those are two wordings of one sample. Do not average them, and do not multiply either by a percentage to invent a headcount the release does not print. "Almost all (95%) survey respondents experienced security problems in production APIs, with 23% suffering breaches as a result of API security inadequacies." Separately: "API security incidents more than doubled within the past 12 months, with 37% of respondents experiencing an incident, compared to just 17% in 2023." On forgotten interfaces: "An alarming 70% highlight Zombie APIs as a great or strong concern, up from 54% in 2023." And "66% of survey respondents" indicated they are managing more than 100 APIs (Salt Security, State of API Security Report, 2024). 95%, 23%, 37%, 17%, 70%, 54%, and 66% are shares of respondents in that survey. They are not shares of endpoints.
The customer telemetry is a second population, and the release keeps it in a different section. Salt's analysis of its own customer data found a 167% increase in API counts over the past 12 months, and that almost two-thirds (61%) of attacks in that data are unauthenticated, with 13% of attack attempts explicitly targeting internal APIs. 167% and 61% and 13% are not 95% and not 70%. One set is what professionals answered. The other is attack and inventory telemetry from customers of a company that sells API security. Salt describes itself, in that release, as an API security company. That description is theirs. A callback you cannot list is the shape of the data-flow blindspot OWASP defined. It is not evidence that 70% of your subscriptions are zombies, and it is not evidence that 23% of agencies have been breached through a webhook. The 70-to-54 comparison is the comparison they print. Quote it as their comparison of concern, year to year, and do not promote it into a rate of forgotten URLs.
Do the three proofs against one destination you can point at. First, the list. In the cloud account, the CI project, the vendor console, and the repository the client owns, you can see the URL, the event types, and the secret header if there is one. You can name the screen. A partner who says "it posts to our status bot" has described their bot. You have not listed the destination until you have opened the subscription. Second, the move. You change the URL to one in an account you or the client administer, or you delete the subscription and create the replacement yourself. The old URL should no longer be the target. Adding a second subscription beside the first, so your address also receives a copy, leaves the partner's address on the list. That is a mirror. It is not a move. Third, the proof. You cause one new event — a test order, a test ticket, the smallest event the subscription actually sends, not a different event type you hope is equivalent. It arrives at the address you hold. You have a line for the old address: you could watch it and nothing arrived, or you cannot watch it, and you have written that. If the third line says "unknown," the old destination is not retired. It is retired in the one place you checked.
Three moves that look like a move and leave the events going where they went. Deleting the URL from the README and the runbook, which hides the documentation and leaves the subscription. Rotating the signing secret and emailing the new value to the partner so their endpoint keeps verifying, which is a new credential on the same destination — the key article, done backwards. Asking the partner to forward you a copy "when something important happens," which is the inventory blank, still blank, plus a person in the path. The environment question from OWASP's documentation blindspot sits beside the flow. A callback that points at production from a staging project, or at staging from production, is not fixed by moving the URL to a prettier domain. Write the environment on the same line as the address. A flow you cannot name the environment of is a flow you have not listed.
Where the events land is an ownership question the marketing clause does not answer. The white-label terms we publish put the work in the agency's repositories, the agency's issue tracker, and the agency's CI, assign the work product on delivery, and say we publish nothing about the engagement or the client without written permission. A webhook is not a case study. It is a pipe. Permission not to be named on a website does not, by itself, list the URLs that receive the client's orders. Agency engagements of this kind sit under the non-disclosure we would sign, so they are not on this site as case studies. A case study would be the wrong shape for a destination anyway. The proof is one event that arrived where you can see it, and one line for the address you could not see. Neither belongs in a portfolio.
There is a version of this where hiring the move is the wrong purchase. The work is not sold, so there is no client and no event a build could be sending. The client asked to meet the people who will write the code, and the conversation you are in is that introduction, not a callback. The room only has a slide. Or the buyer wants a template inventory and does not have a console to open. A spreadsheet that quotes 70% and has never named a URL is a brochure. The criteria for choosing a firm, when that is the actual decision, are the ones on the page for a top saas development company. They do not rank anyone, including us.
When events about the client are already arriving at an address you cannot see, the missing object is specific. A list of destinations, a URL in an account you administer, and a new event you watched. A white label software development partner that expects this will put the subscriptions in the client's organization, or in yours, before the first deploy, because a callback created in a console you cannot open cannot be moved by the person whose name is on the invoice. One that can only edit notifications from a laptop it takes home is telling you who receives the client. Where the next slice is one capability and the acceptance sentence names the destination, an AI integration sprint is the shape that can require the three proofs as the definition of done. Where you are not sure which addresses the current engagements already post to, a two-week AI readiness assessment maps the flows before anyone scopes a rebuild. The findings are yours. They are not a promise that a survey of API concern applies to you, and they are not a rate.
Before you tell the client the integration is yours, do the three proofs on one real destination. List it where it lives. Move it to an address you hold. Show that a new event arrives there, and write the old address you could not see. A callback you cannot name is still a way out. The screen that says the deploy is green does not say who else is still being told. Which event already arrived, as opposed to which address you moved, is which webhook did that event hit?. A destination is not a delivery.
Find this useful? Tell Google to show you more of it.