#Tableau APIs & Embedding17 人がディスカッション中

Hi @Wascar Perez

thanks for sharing the details with the community. 

What I would try if I were in your shoes: set embed_password=True with your REST API pipeline as usual, then try to unset the embedded password with the VizPortal API. It is undocumented and unofficial, but you just need to trace your browser traffic with dev tools when using the Server UI then google the VizPortal API info a bit to see how to authenticate against it and you will figure it easily if you are a developer. 

I checked on my sandbox. It is this endpoint:

@raju Prasad​ 

Hi, maybe you can take a look of:

https://www.youtube.com/watch?v=2sPJfxeoJ90

https://github.com/TheInformationLab/tableau_langchain_starter_kit

https://python.langchain.com/docs/integrations/tools/tableau/

If this post resolves the question, would you be so kind to "Select as Best"?. This will help other users find the same answer/resolution and help community keep track of answered questions. Thank you.

Regards,

Diego Martinez

Tableau Visionary and Forums Ambassador

Hey Tony, 

The core fix here is architectural: your Apex REST endpoint should do almost nothing synchronously. Right now, if your handler is doing lead validation, dedup logic, or DML inline before returning a response, that's what's blowing past the 504 threshold under load, real business logic execution easily drifts past 2-3 seconds, which the gateway treats as a dropped connection. 

Recommended pattern: 

1. Inbound Apex REST method only: validates the payload/signature, publishes a Platform Event with the raw data, and returns HTTP 200 immediately. Nothing else happens in that thread. 

2. A separate Platform Event trigger picks up the event asynchronously, does your actual business validation, then enqueues a Queueable job (implementing Queueable, Database.AllowsCallouts if you need outbound calls) to do the real processing/DML. 

3. Cap callouts below Salesforce's 100-per-transaction limit, chain overflow records to a new Queueable automatically rather than dropping them. 

4. If Apex's async queue itself hits a capacity rejection under heavy concurrent load, catch that exception and fall back to a Scheduled job (e.g., retry in ~20 seconds) so nothing gets silently dropped. 

This decouples network response time from your actual processing time entirely, so gateway timeouts stop being a factor regardless of how complex the downstream logic is. Your observation that direct REST calls resolve under 150ms but webhooks spike under concurrency confirms it's specifically the synchronous processing inside the handler causing the bottleneck, not the API layer itself. 

Also worth adding: idempotency (dedupe on a unique payload ID) since Platform Events and async retries can occasionally redeliver, and Named Credentials for any outbound calls so secrets stay out of code.

Hi Raju, 

 Recently we have built a Tableau Dashboard Extension that adds a chat panel right inside the dashboard — so instead of eyeballing charts, users can just ask questions in plain English ("what drove the drop in Q2 expenses?", "compare loan fees to expense spend") and get grounded, numeric answers. 

How it works: 

• One lightweight local/hosted backend serves multiple dashboards at once — the model automatically figures out which dataset(s) a question is about, and can even blend two datasets in one answer.
• Every answer is computed by the LLM writing read-only SQL against a real snapshot database (using Tableau's own Hyper engine) — not hallucinated numbers, not a live query against the workbook. This keeps answers fast, accurate, and safe even on 10M+ row extracts.
• Each dataset ships with auto-generated reference docs (a description + data glossary) so the model understands field meanings, grain, and caveats before answering.
• An admin flow can onboard a brand-new Tableau Cloud workbook automatically: pull it via the REST API, extract the embedded data, and have the LLM draft the descriptive docs itself.
• Row-level-security workbooks are auto-detected and blocked from onboarding unless explicitly overridden, so a shared snapshot never leaks restricted rows.

Please upvote this response if this will be helpful to you. 

Regards 

Rajneesh

Hi @Umesh Chorge

dealing with WebEditing and credentials can be a bit unstable. I've seen a lot of instances over the years were credentials for some mysterious reasons were not committed or using old ones or using credentials from another tenants while the Analysts were working daily on multiples tenants.  

This is one example: 

As you seem to work with embedded data source directly in the workbook, as Diego said in his earlier post, use published data sources. To keep your datasource stable and modify your workbook content irrelevant of Athena connections even in WebEdit. 

And ideally you modify your published data sources using Tableau Desktop if you can.