For webservice callouts, I assume the same rules apply, but I just wanted to double check. I haven't found any information about Platform Events and Webservices. I assume I would just make it a @future method to avoid erroring out?

6 Answers 6


Just to clarify: The question appears to be "CAN" you do it, not "SHOULD" you do it.

So the answer is YES, you can execute a callout from a trigger on the Platform Event object, much like you could when you, say, insert an Account.

I refuse to comment on whether or not you SHOULD do it - there are experts in architecture here who are much smarter than I am. :)

  • 1
    As this is the top ranked answer on Google right now, I feel the need to clarify: You CAN execute a callout by creating ANOTHER async operation (future or queueable) that is invoked by the platform event trigger. You CANNOT make a callout directly from the platform event trigger itself (see next best answer). Jun 29, 2022 at 14:02
  • I can't see any reason why we SHOULDN'T do callouts to handle a platform event, using @future methods, or better, Queuable classes. A platform event can be published by any process so some of them might need a callout to be properly handled. I don't think there is a general rule here. Oct 23, 2022 at 14:54

Older question but felt compelled to add an answer, as I was confused by what was presented here so far.

If you are asking "can I make an Apex HTTP Callout from my Apex Platform Event Trigger?" then the answer is NO.

System.CalloutException: Callout from triggers are currently not supported.

Here's John Brock, the product owner for Platform Events, in the Platform Events success community chatter group March 7, 2019 (a comment against this posting):

Longer term we also hope to relax some of the limits and restrictions on Platform Event triggers since they are executed asynchronously -- such as, I would love to be able to do callouts directly from Apex Triggers.

What you can do, and I think the OP alluded to this when mentioning @future, is to call an asynchronous context like @future or Queueable from your trigger, and do the HTTP Callout from that context instead.

  • 1
    In an effort to get support for this, I raised an idea.
    – Phil W
    Jul 16, 2023 at 6:55

Yes, Even I was wondering with the same kind of questions when I first heard about platform event in Salesforce.

But after taking up Platform Event Trailhead Module, All of my doubts got cleared And here are some major takeaway from the same :

  1. Platform events are like other salesforce records(but can't be edited or deleted.)
  2. You can perform only after insert(in triggers).
  3. After you (publisher) create a platform event, consumer(subscriber) can listen to it.

But i don't think that you would make a web service callout after creating a platform event(just ponder over this use case again and you will know that this is not proper use case for platform events, because when you are creating a platform event, your subscribers which are connected to event channel is already polling/listening for this event).

But still, if you are curious to try out, Because platform events are published by inserting the event sObjects, standard API request limits apply. Referencing a link for further help.

Considerations for Publishing and Subscribing to Platform Events with Apex and API

  • 1
    I am not sure what you mean by: because when you are creating a platform event, your subscribers which are connected to event channel is already polling/listening for this event). can you explain this again?
    – Olivia
    Mar 5, 2018 at 16:48
  • "our subscribers which are connected to event channel is already polling/listening for this event" ---- Unless you have code in a Community or LtngOut that you want to notify. That code can't listen for platform events. Sep 27, 2019 at 14:29

The event driven architecture approach is subscribing to the platform event in the external service instead of calling a external service - but this only works if you are in control of the service you wan't to call

  • Interesting. What would be the drawback to calling it in the trigger? why would it be better to call it in the service?
    – Olivia
    Mar 4, 2018 at 20:31
  • @olivia not calling it "in" the service but implementing a service "subscribing" to this event - if you are interested i can post a few links to get into event driven architecture and unified log
    – pelim
    Mar 4, 2018 at 21:21

I found this blog: https://developer.salesforce.com/blogs/developer-relations/2017/05/first-impressions-platform-events-salesforce-enterprise-messaging-platform.html

One of the items they hit on is the point of the Platform Events. He says:

The vision for Platform Events is simple: Empower our customers to increase business productivity and efficiency through integrations via events. We want to enable customers to create more integrations between Salesforce and their systems. Using Platform Events, customers can support more interaction between Salesforce and their data. The goal is to reduce the number of point-to-point integrations and expand on the existing capabilities of our other integration options such as Outbound Messaging, Apex Callouts, and the Streaming API.

I interpret this as a green light to connect the two. If anyone has any thoughts on this feel free to comment.


It seems like a rather odd scenario to need to use a platform event, but I think I'm hitting one of those scenarios. I have an integration receiving messages via platform events. These process a number of payloads in bulk. Since the bulk operation can hit governor limits, I have limit checks around various operations. If there is one of the records in the bulk that will cause the limits to be hit, we stop processing that message and add it to a list. An after trigger then looks at the list, and if it is non-empty daisy chain queuable classes to process these messages one at a time. There are also error conditions that force the one at a time processing.

So the point is a process can only invoke queueable once. And to add the service call into the daisy chain list will inherently make it less reliable. @future calls can be silently dropped, so also is a bad idea if we want to reliably perform the callouts.

The solution seems to be to fire the platform event, and allow that to use queueable to do the callouts. This avoids having a nested chain of different types of queueable callouts, and keeps the system in a reliable state. It also allows for better bulkification and logging.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .