API Key, Download Link, Portal Login, or Scheduled Delivery: 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"? Would they rather never have to do anything at all, and just have the file show up? 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 four 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.
• Scheduled delivery. For a customer who doesn't even want to remember to open a link. Set a format and a recurring schedule once, and the file arrives on its own - to their email inbox, or straight to their own FTP/SFTP server if their systems expect to find it waiting there. Nobody on either end has to trigger anything, ever again.

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. If nobody on their end wants to have to remember anything at all - no login to check, no link to click - it's scheduled delivery instead. Most businesses end up handing out several of these 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 four 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, a consumer portal login covers the no-code case, and a scheduled transfer covers the "don't make them do anything at all" case - by email, by FTP/SFTP straight to their own server, or both at once for different recipients on the same schedule. All four read 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.