We were working on getting it documented and it shipped yesterday. Sorry for the delay!

https://fusionauth.io/docs/v1/tech/apis/entity-management/ outlines all the relevant APIs, including entity CRUD.

You might also be interested in the client credentials grant, one of the main use cases:

configuring entities for the client credentials grant: https://fusionauth.io/docs/v1/tech/oauth/#configure-entities an example client credentials grant: https://fusionauth.io/docs/v1/tech/oauth/#example-client-credentials-grant

You have a few options.

Limit Query One option is to find a way to limit your search by logical increments. For example, if you are searching on users you may consider obtaining and appending results by first name in a loop.

As an example:

for (letter in [a...z]) { query + " AND user email starts with $letter" // do work } Use Version > 1.24.0 when pulling something like users

https://fusionauth.io/docs/v1/tech/apis/users/#request-parameters-12

Request Parameters accurateTotal [Boolean] OPTIONAL Defaults to false AVAILABLE SINCE 1.24.0 Set this value equal to true to receive an accurate hit count on the API response. By default the search engine will limit the hit count to 10,000 users. This means that even if your query may match more than 10,000 users, the returned total count will be 10,000. This is adequate for many use cases such as pagination and general purpose queries. If you are looking for an accurate user count that can exceed 10,000 matches, you will want to set this value equal to true.

Yes.

The only thing you can't create via the API is another API key. You can track that functionality on this issue.

See the tenant documentation for more.

Yes. You can use the tenant API or any of the client libraries to created, read, update and delete tenants and all their configuration.

Version 1.12 is quite an old version. I would recommend upgrading and see if you can recreate the issue.

Double check that you are calling the precise API URL.

http://<hostname>/api/login will work, but http://<hostname>//api/login will not. Though some user agents ignore the double //, FusionAuth treats them as two different URLs, and returns HTML which the API client doesn't know how to parse (hence the error message).

The JWT TTL can be configured per application, so if you were using a different application for OIDC vs an API - then you could do it.

But if you don't want to use multiple applications, then it is not possible, at least currently.

I could see a use case for asking for a JWT with a TTL equal to or less than the configuration and that request being honored, that could be a feature request. But as of right now, the only option is different applications.

These are generated in the UI. So the values are not available from the API.

However you can derive them yourself as well. We just take the URL + /oauth2/authorize?... + redirect_uri etc.

From the user search docs, for the database search engine:

Regular expressions may not be used. A value of * will match all records.

For the elasticsearch search engine, you are limited to 10,000 records returned due to this bug: https://github.com/FusionAuth/fusionauth-issues/issues/494

Here's docs on how to switch between them: https://fusionauth.io/docs/v1/tech/tutorials/switch-search-engines

If you use the request body you should be fine. You can do a lot more than 500 if you like.

I would start with 5-10k and see how performance is.

Is this what you are looking for?: https://fusionauth.io/docs/v1/tech/apis/registrations#create-a-user-and-registration-combined

That API does return a token as of v1.17.0.

You can use the user.data and registration.data fields to store arbitrary key value data.

If the metadata is associated with the user, use user.data. If it is associated with the user's account for a given application, use registration.data.

Note that this field is read/write via the API, but only readable via the administrative UI.

Here are some notes about the limits of these fields: https://fusionauth.io/community/forum/topic/89/how-large-can-the-data-field-be-for-any-of-the-fusionauth-resources

And for the latter option, should I use a webhook for registration events

If you want a separate database, that's the way to do it. Listen for a webhook and create the records then.

Whether you should use the data fields or a separate database depends on what you are trying to do. The data fields are simpler and more tightly tied to the user records. You can also query them, but you'll be writing elasticsearch queries.

If you'd rather write straight SQL or will be storing lots and lots of data about a user (for example, their entire login history for analytics), then a separate database might work better. Of course, that's another system to maintain, so more complexity is the tradeoff.

If you want to add or remove a registration from a user (registrations are how a user is authorized to use an application) you could either allow someone to use the FusionAuth admin screen (possibly with a limited role) or you could use the API to build your own more limited interface.

Here's the API call you would want for this specific use case: https://fusionauth.io/docs/v1/tech/apis/registrations#delete-a-user-registration

@fusionauth_user, are you using Klemen's schema or did you create your own?

Symmetric keys are not returned on the JWKS endpoint, as they don't have a public key. Per the docs this api:

returns public keys generated by FusionAuth, used to cryptographically verify JWTs using the JSON Web Key format

If you create an RSA or EC key which is an asymmetric key pair - the public key will be returned on the JWKS endpoint. If you don’t have any key pairs configured , it will be empty. Out of the box, you’ll only have one HMAC key which we don’t publish in JWKS.

The system status API call is the best solution here. It will return a status code when you (or your application load balancer, CDN or other software system) makes a GET request on <faurl>/api/status. It'll either be a 200 if things are all good or a 500 if there are any issues with the system.

It's documented more fully here: https://fusionauth.io/docs/v1/tech/apis/system#system-status

Note that this endpoint is not currently supported by the client libraries, but is just a curl away.

There is no way to create API keys from the API.

You can bootstrap the system with an API key using Kickstart. Kickstart would allow you to create one or more API keys, which can optionally scoped to a tenant. More on Kickstart: https://fusionauth.io/docs/v1/tech/installation-guide/kickstart

However, this doesn't solve the issue of dynamically creating a tenant scoped API key. If that's a use case for which you need support, please file a github issue: https://github.com/fusionauth/fusionauth-issues with more detail.

Yes, you want to use sourceTenantId when creating the tenant

You can keep a tenant around or use a particular one as the template, and then always create a new tenant using the sourceTenanId. This does not do a merge however, so if you want specific values, you’d want to do something like:

Call create w/ sourceTenantId Consume the response and then modify what you want Call update or patch with the new values

The client libraries all consume the same REST API, so you can use that as a reference: https://fusionauth.io/docs/v1/tech/apis/

This seems like a case for the client credentials grant, which is unfortunately still on the roadmap: https://github.com/FusionAuth/fusionauth-issues/issues/155 Not sure that would help with the rotation, though. Just like username and password approach, I don't believe the credentials grant lets you rotate creds in.

Other options: you could look into a third party api management solution (as mentioned here).

Could you use longer lived JWTs but then a webhook to revoke them, as outlined here: https://fusionauth.io/learn/expert-advice/tokens/revoking-jwts ?

You can control the duration on an application by application basis (so all JWTs issued by one application have to have the same length). You could create a 'services' application that only these services would have registrations with, not sure if that would work.