Hello Msommer,

I have followed your Steps to reproduce and am getting the same result.  Investigating now, and will be in touch soon.

Status Update:

I have been unable to find a cause and have reached out to Senior Engineers for support. I expect that sometime tomorrow we will be able to identify what is causing the failure and provide a ETA when we expect it to be fixed.

Thank you for your patience.

Thanks Michael, 

I appreciate the updates!

Msommer,

Can you try again now? I believe we have resolved the issue, but am not absolutely sure its the one affecting you.

Hello Michael,

I am still getting the 404 not found. 

Hmmm, very strange. We are getting inconsistent behavior. Continuing my investigations.

Are you now getting the expected results? 

One thing to note. For this api call, I am entering a dummy origin parameter.

When I inspect the returned JWT, it looks correct, but would passing the jwt/token to this api with some dummy origin result in a NOT FOUND? 

Also, side question about this api. Are there any document side effects associated with this call such as permissions mutations or the doc being published as a result of calling this API for a particular document? 

`Not Found` should only be returned if the `document` or the `embed` can not be found. I believe there is an issue with the data-store on our side causing the issue. That is under investigation.

No, there are no side-effects with the calls themselves. Creating an embed and embedding cause no change in permission to the documents in and off themselves. Where you post the embed and what users do on the document in the embed could affect access, but these API calls themselves do not.

Thanks!

Hey Msommer, we believe we have been able to identify the issue. The command listed in the API docs is unfortunately misconfigured and there is a small error in the documentation as well that would have prevented the iframe from working properly. I’ll list out the details of that here while we work on the fixes.

The documentation for the embedded viewer has the iframe’s src parameter wrapped in angle brackets like so 

<iframe
  src='<https://lucid.app/embeds?token=:token>'
></iframe>

It should not contain the brackets and look more like the following 

<iframe
  src='https://lucid.app/embeds?token=:token'
></iframe>

The other issue is in the Try It feature for the embedded viewer documentation. It has the url listed as 

https://api.lucid.co/embeds

This is incorrect. It should be the following

https://lucid.app/embeds

For now, I would recommend testing the embed iframe in some form of sandbox environment that lets you add custom html with the fixes I described above instead of the Try It feature in the documentation. Something like W3Schools html sandbox for example.

We are working on fixes to the documentation to remedy those issues. In the meantime, if you run into any additional issues please let us know. 

Thanks for the response, this is helpful!

I have been building something in a sandbox environment and will be testing soon.

I would like to confirm the following.

You mention the embed viewer API Try it feature should point to `https://lucid.app/embeds`, is this just for the documentation or should I also be pointing to this endpoint in the application I am building?

Also is the endpoint correct for these API’s?

https://developer.lucid.co/v1.0/reference/createembed

https://developer.lucid.co/reference/documentembedstoken

https://developer.lucid.co/reference/getorexportdocument

The `https://lucid.app/embeds….` is the URI that I would use for both testing and for the application you are building.

There is a long form explanation for this, but the short answer is yes. The other endpoints you listed are correct with regards to their URL. The embedded viewer is a unique case where the `api.lucid.co` URI is not used in favor of the `lucid.app` counterpart. 

Please let me know if that answers your question and if you run into any additional issues. 

​@chasefreeman ​@Michael B 

I finally built a sandbox application that correctly 

1. creates an access token
2. gets an embedId
3. creates an embed session token

However when making a GET request to the  Embed Viewer endpoint with the embed session token and the modified url of https://lucid.app/embeds I am still getting a 404 not found. 

My request looks something like this:

https://lucid.app/embeds?token=<EMBED_SESSION_TOKEN>

with headers

{ 'Lucid-Api-Version': '1' }, 

The Lucidchart url is: https://lucid.app/lucidchart/0aae9cf6-910c-42e2-a3b7-520de04788a3/edit?viewport_loc=-484%2C-279%2C3072%2C1519%2C0_0&invitationId=inv_083051cd-42b6-49d8-835b-4b0170f088ca

Any ideas why I might still be getting a 404?

1. When creating an embed session token, does the origin parameter inform how the embed viewer endpoint behaves? Like if the source making the embed viewer call does not match the origin param, will a 404 be returned? 
2. Has the url changed, should it still be https://lucid.app/embeds?

Hello MSommer,

I am reviewing your post and the logs to help figure out whats happening. I will be in touch.

I still have not found an answer to why you are seeing a 404.  For certainty, if you hit the embed route with a fake token, what do you get? An image of me doing it is attached. I expect you would see the same. (Of course, a real token should return the embed)

For your questions:

1. The “origin” defines what domain is allowed to show your embed. When the embed session token is used to retreive the embed, we will check the host of the request `referrer` header and it must match the “origin” provided when the session token was generated. This prevents attacks where a different site gets the token and tries to render the embed.
2. Yes, https://lucid.app/embeds is the correct route to retreive the embedded document web component. It is enabled to be wrapped in an iframe.

Thanks ​@Michael B 

I still get a 404 from my sandbox app when using a fake embed token.

From inspecting my token, the scopes are

```

offline_access

user.profile

lucidchart.document.content.share.embed

lucidchart.document.content:readonly

lucidchart.document.app.picker.share.embed

```

And I can share the embedId that I created by calling createEmbed if you would like. 

I believe the 404 is being caused by either the host being wrong (lucid.app/embeds) or something in the query parameter string which is malformed and causing our system to not detect which route it is. A 404 is returned before any business logic, so its nothing with the token or embed. The issue must be in the route or parameters. For example, here is what I see if I try “embed” instead of “embeds”

Hey ​@Michael B 

I have resolved my issue. Your comments helped out a lot. 

Thanks for all your help!

Fantastic. Glad to hear this is resolved before we get into the holiday window and communication slows down.