Create embed user with API

(Scott Vickers) #1

We need to create a user in Looker before we try to embed a dashboard but having trouble figuring out if it is even possible to create one with the API. I’ve tried posting to the create user endpoint with embedcredentials populated, but no luck. There is also no endpoint listed in the documentation to create embed credentials on their own like you can with other credential types. Has anybody had any luck with this?

(bernard.kavanagh) #2

It is possible to create an embed user via the API with the create user endpoint as long as you provide arguments for the credentials_embed array.

It is also possible to create users with the examples provided in our SSO examples GitHub repository. This doubles as an efficient way to build the embed URL too.

For more information please see our sso embed documentation.

Hoping this helps!

(Scott Vickers) #3

I gave that a shot yesterday but realized none of the embedded credentials were being sent to the api because in the swagger file they are all marked as readonly, this causes the generated .net client to not serialize them to json at all when posting the new user. That seems like an error in the swagger definition.

But I corrected it on my end so embed creds are definitely being posted, but the user is still being created as just a standard looker user. Here is the sample request:

Authorization: Bearer xxx
User-Agent: FxVersion/4.6.26814.03 Looker.LookerClient/
Request-Id: |d797b619-4c8dcf38d2aec6ba.2.
Content-Type: application/json; charset=utf-8
Content-Length: 137
  "first_name": "test",
  "last_name": "test",
  "credentials_embed": [
      "external_user_id": "blah-blah"


HTTP/1.1 200 OK
Server: nginx/1.12.2
Date: Mon, 08 Oct 2018 20:50:50 GMT
Content-Type: application/json;charset=utf-8
Content-Length: 831
Connection: keep-alive
Set-Cookie: looker.browser=12; expires=Thu, 07 Oct 2021 20:50:50 -0000; HttpOnly
Vary: Accept-Encoding
X-Content-Type-Options: nosniff

  "id": 88,
  "first_name": "test",
  "last_name": "test",
  "email": null,
  "is_disabled": false,
  "avatar_url": "https:\/\/\/avatar\/d41d8cd98f00b204e9800998ecf8427e?s=156&d=blank",
  "home_space_id": "111",
  "personal_space_id": 111,
  "credentials_email": null,
  "credentials_totp": null,
  "credentials_ldap": null,
  "credentials_google": null,
  "credentials_saml": null,
  "credentials_oidc": null,
  "credentials_api": null,
  "credentials_api3": [
  "credentials_embed": [
  "credentials_looker_openid": null,
  "locale": "en",
  "looker_versions": [
  "ui_state": null,
  "sessions": [
  "presumed_looker_employee": false,
  "verified_looker_employee": false,
  "embed_group_space_id": null,
  "display_name": "test test",
  "role_ids": [
  "group_ids": [
  "url": "https:\/\/localhost:19999\/api\/3.0\/users\/88",
  "can": {
    "show": true,
    "index": true,
    "show_details": true,
    "index_details": true,
    "sudo": true

(molly.lippsett) #4

Hey Scott,

Would you mind explaining your use case for creating the user first?

When we create users with a script at the same time as the embed url, as shown in our SSO examples GitHub repository that Bernard linked to above, we declare the permissions that user should have as part of creating them.

Embed users don’t usually get direct access to Looker - they access through the application or site where you’re embedding, so they don’t have credentials in the same way that Looker users do.


(Scott Vickers) #5

Hi Molly - We are rolling our own filter implementation that is outside of the iframe. In order to get potential filter values we are using the query api, but this must be run in the context of the current user for data security. In our system we store the clientid and secret with our user records, if those are blank then we hit the endpoint to create api3 credentials for the user. This is a problem if the user does not yet exist in Looker.

To mitigate not being able to create the user with the api, we are showing an intermediate page after they login to our system that has a 1x1 iframe pointing to a blank dashboard. This way we are sure the user now exists in Looker. A bit of a hack for sure and something we will always need to remember to carry forward as the product evolves.

(Paul Roberts) #6

If you look at the previous comment. The SSO method of integrating and doing exactly what you are after is in there. We are doing this for our current and two future projects and it works without the need for API integration and allows for queries to be run as the current user, with external filtering. You just need to know how to compile the IFrame URL.


(Chris M.) #7

Hi Molly,

I’d like to chime in because we’re doing something similar. We’d like to create an embed user with API credentials, so that we can display embedded iframes and custom graphs using data from the API in our own portal. Part of the reason we want to do this is because loading several iframes at a time can be cumbersome.

We’d like to do this by creating the embedded user first (on login to the portal) with API keys, and then generate the embeds/graphs afterwards. I suppose we could work around this by loading the iframe from our portal server, doing a search for the user (based on the external_id), and then generating the API keys, but this is a little hacky and doesn’t seem to be a good practice.

(leticia.esparza) #8

Hey @chrism,

I hope all is well! Would you mind elaborating on why the SSO embedding option would not fulfill the needs of this use case? Just trying to ensure that I have a clear understanding on my end.



(Chris M.) #9

Hi Leticia,

The main use case here is mixed use of embeds and API calls. There are two reasons for this:

  1. Speed - in one dashboard of our portal, we’re embedding 6 iframes, 4 of which are single stat visualizations. Loading up 6 iframes is slow, and we’d like to display the single stat metrics without an iframe, so that it will render faster.

  2. Look and feel - given the example in #1, while the graph type visualizations look good while embedded as an iframe, the single stat metrics don’t fit in as well. I think they will look much better if we can style them using our own CSS framework.

I’ve thought about creating a regular user via the API, but then I’m not sure if the embeds will work unless Looker supports passing the access token as a GET variable. Even if that works, I’d rather not have the Looker access token accessible by the user, and would prefer to route any API type requests through our own service.



(molly.lippsett) #10

Hi @chrism

Thanks for the explanation! We might be able to use the login_user endpoint to create access tokens for your embed users - these users would already need to exist, but then you could use their individual access tokens for API calls.