I've been reading the documentation bug I can't seem to find information about managing "developers". I see details about user (/api/users).

How can I create a developer and create a key for him, via API?Having a developer API Key, is there a way to access the details of that developer? For example, The developer will do a call to an endpoint with his key, and I want to access his name. What endpoint could I use, to access the developer information, just having his key (because that's what he did the request with)?

I'm afraid not - Tyk assumes you are running in hashed token mode, so tokens are encoded and non-retrievable, they are listed within the developer object once the key request is approved.

However, you the key request will give you a developer ID and approving it will give you the access token. If you wish to track the two unencrypted components together, you can store this separately outside of Tyk.

hmmm wouldn't need to know the token. @Martin The use case would be, based on a Custom fields of that developer, do a specific task on the API.

Developer does request /task {"data":"something"} -H "Auth: token-XYZ"Tyk validates token, does metrics, whatever tyk does internally, and pass request to API and passing Auth token alsoInternal API grabbs Auth Token from headers, and does a /developer -H "Auth: token-XYZ" , this would return the respective developer data like his name, custom fields. I would need access to one of those custom fields.

Yes this is totally, possible, in fact, the Develoepr portal does this for you in some way by embedding the developer's sign-up meta-data in the actual token metadata so you can do a reverse lookup in the Tyk API.

So:

A user signs up on portal and enrolls in API

The portal generates a token

Dev uses Token, it gets vcalidated by Tyk etc.

Your service can then retrieve the raw token (the inbound Auth header value and in the meta_data field of the session object will get something like this:

So I would need to use a Transformation, and add to the Internal Headers the fields I want to access

Yes, if you don't want to request the data using an introspection API call back to the gateway from your app, you can just filter them out of the header.

igama:

Or is the session object/headers already available to the internal API?

The session object is available via the REST API, so your service could grab the token header, then request the session, and from that the user (or toher metadata).

Both are feasible, it's up to you, personally I prefer the first option because it saves you a round trip. But it depends on what data you want, only the users meta-data (the key request and sign-up additional fields) are embedded.

For one, your JSON isn't valid, running it through a linter tells me that the comma after "sdf" needs to go (if you check the gateway logs, you would see the output of the json unmarshaller saying something similar):