Don't use a callbacks for this -- you are going to regret it.
The main problem with callbacks are:

• No context -- you don't actually have any idea what's going on in the app.
• Its hard to control when the callback actually fires -- and more importantly when you don't want it to fire (like for example when loading fixtures).
• It puts too much responsibility on the model.
• You can't test the callback logic in isolation from creating/updating/destroying the record.

I really can't understate this when you seem to be dealing with a third party API as well. Using an implicit mechanism like callbacks when you're touching the application boundary is a really bad idea. The whole idea of piping everything through a single method is also not sound.

Instead you can use patterns such as service objects to handle the "transformations" of the model.

class UserCreationService
  def initialize(user)
    @user = user
  end

  def perform
    # do something with @user
  end
end


class UserInactivationService
  def initialize(user)
    @user = user
  end

  def perform
    # do something with @user
  end
end

These do a single job and are easy to test and will only fire when you explicitly want them to. ActiveJob is actually an example of this pattern.