Creator intelligence has outgrown the dashboard. Brands, agencies, and creator-economy platforms want creator data inside the workflows where decisions happen: campaign planning agents, CRM enrichments, internal copilots, marketplace tools.
In those workflows, the buyer is often software, not a human at a pricing page. An agent matching a campaign brief, fetching a creator profile, generating lookalikes, or scoring a shortlist needs a way to pay for that one request when the workflow demands it.
What we're launching
Influship now sells access to its API per request, over HTTP, using two protocols.
An x402 client hits a paid endpoint without an X-API-Key, gets back a 402 Payment Required response, signs a USDC payment on Base, and retries with the payment attached. An MPP client does the same dance with a Stripe-backed Shared Payment Token or USDC on Tempo, reading the supported methods from the WWW-Authenticate: Payment header on the 402.
Both protocols live on the same endpoints. A single 402 can advertise an x402 challenge and an MPP challenge at the same time, and the client picks whichever rail it speaks.
For production traffic, the API key is still the right choice: cheaper per call, tied to an account, integrated with the dashboard. Per-request payment fits a different case: agents, marketplaces, experiments, and integrations where forcing a human to sign up before a single API call doesn't make sense.
Why agentic payments matter for APIs
Most APIs assume a human onboarding flow. A developer signs up, adds a card, picks a plan, generates a key, reads the docs, then writes the integration. That flow still works for most production traffic.
Agents change the assumption. If an agent inside a campaign planning workflow has to pause, prompt a human to register a new vendor, and resume, most agents won't get past the first step. An agent needs to find the service, read the price, pay, and use the response without breaking the loop.
Once an API becomes machine-discoverable and machine-payable, you stop distributing it through a sales motion. You distribute it through software that calls it.
Why creator intelligence fits this model
Creator intelligence shows up as discrete questions. A brand running a campaign asks things like:
- Who are the best creators for this campaign?
- Which creators are similar to our top performers?
- Does this creator match our audience and brand requirements?
- What does this creator's profile look like?
- Which influencers should we shortlist from this category?
Each one maps to a specific API call, and the asking doesn't have to start in a dashboard. It can start inside whatever the team is already using: a campaign planner, a CRM enrichment, a marketplace pricing engine, a research agent building a shortlist.
Influship already exposes those calls: creator search, profile, autocomplete, lookalikes, campaign-fit matching, and raw creator and post data. With per-request payment, another system can fire one of them and move on. A CRM enrichment hits the profile endpoint once. A campaign planner paginates through a shortlist. A research agent buys a single profile without anyone standing up a new vendor account.
Supporting both x402 and MPP
The agentic-payment ecosystem hasn't picked a winner, and we don't want to make developers wait for one. Different clients fit different rails: USDC on Base for stablecoin-native stacks, Stripe Shared Payment Tokens for teams already on Stripe, USDC on Tempo for some of the newer agent frameworks. Each of those routes through either x402 or MPP, and the choice comes from what the agent framework already supports.
Influship serves both on the same endpoints. A client that speaks x402 pays x402. A client that speaks MPP pays MPP. A client that speaks both reads two challenges off the 402 and picks. None of this requires Influship, or anyone else, to crown a single payment standard before creator intelligence becomes reachable to agents.
Discovery is part of the product
Paying for a service requires finding it first. An agent needs to know what an endpoint does, what it takes, what it returns, what it costs, and how to pay. Influship lists its paid endpoints in the x402 Bazaar and the MPP services directory, so an agent that supports either protocol can discover them through the directory the protocol already maintains.
For an API, documentation alone isn't enough. Developers read it; agents don't. The same details (endpoints, schemas, prices, payment methods) need to be machine-readable, in a place agents already check.
Contributing to the ecosystem
Building on this didn't only mean integrating two protocols. Our CTO, Elliot Padfield, also wrote the Fastify adapter for x402 payment middleware and contributed it back to the x402 project. The adapter ships the middleware itself, an example app, and test coverage for settlement, response handling, and the edge cases a Fastify service hits in real traffic.
We wrote it because Influship's external API runs on Fastify, and once it existed there was no reason not to upstream it. Agentic payments only become real infrastructure when the frameworks developers already use have working adapters. Skipping that step keeps the whole idea in a demo state.
What developers can do now
There are now three ways to call Influship. The API key is still the default for production traffic: cheaper per call, account-level limits, integrated with the existing dashboard. An x402-compatible client can pay per request in USDC on Base. An MPP-compatible client can pay per request with a Stripe Shared Payment Token or USDC on Tempo.
All three hit the same endpoints. You can start with whichever model fits the use case and switch later without changing the integration.
Built for where APIs are going
Agentic payments are still early. Plenty has to get figured out before this is production-grade infrastructure for serious money: spending limits agents can't blow past, authorization that lets a user grant per-task budgets, receipts and refunds that work the way humans expect them to, settlement flows that fail safely.
The direction, though, isn't ambiguous. Agents are going to keep buying things from software services, and the APIs they call need a way to charge them without routing every buyer through a sign-up form. Creator intelligence fits that pattern as well as any category: the questions are concrete, the answers are valuable, and they tend to surface inside a workflow rather than a dashboard.
Customers who want a dashboard still have one. Developers who want an API key still have one. What's new is that an agent can call Influship and pay for the call without anyone setting up an account first.
