API Key, Download Link, or Portal Login: How to Choose What to Give a Customer

Once a product catalog lives in one place, the next question isn't really technical - it's about the customer in front of you. Does this account have a developer? Do they work in spreadsheets? Would they rather just log in and click "order"? The honest answer is almost always "it depends who's asking," and the mistake is picking one access method for the whole business instead of matching it to each customer.

The three shapes access takes

• API key. For a customer with their own developer or an existing system that needs to call your catalog directly - a storefront, a marketplace integration, an internal tool. Scoped to read-only, read-and-book, or full read/write, depending on what that system should be trusted to do.
• Download link. For a customer with no developer who's happy opening a spreadsheet or feeding a file into whatever import tool they already run. A standing CSV, XLSX, or JSON link, revocable on its own, with nothing to integrate.
• Portal login. For a customer with neither a developer nor much interest in a spreadsheet. They sign in, see the catalog and prices you've set for them, and place an order directly - no key, no file, no code.

A short test for each customer

If a system on their end needs to call yours programmatically, it's an API key. If a person on their end wants to open a file and doesn't want to log into anything, it's a download link. If a person wants to place their own orders but has no system to integrate at all, it's a portal login. Most businesses end up handing out all three at once, to different customers, off the exact same catalog - which is the point. The access method is a detail about the customer, not a decision about your whole business.

You can change your mind later, per customer

A customer who starts on a download link because they had no developer can move to an API key the day they hire one, without affecting anyone else's access. A partner reselling your catalog at their own markup can still choose any of the three for their own downstream customers, since a child feed supports all three just like a regular feed does.

How Feedwyre approaches this

Every product feed supports all three access methods from day one, so the choice is never "which one does our software support" - it's just which one fits the customer you're looking at right now. Query and Query & Booking keys cover the developer case, a download link covers the spreadsheet case, and a consumer portal login covers the no-code case - all reading the same live catalog, with the same atomic stock safety underneath regardless of which door a given sale came through. Our full decision table in the docs covers a few more specific scenarios, like giving a whole reseller network downstream access under one child feed.